I don't get how this achieves point in time recovery? I assume I'm misunderstanding some fundamental part here.
If the branches are achieved using a COW file system, how does this part from the blog post work?
> Suppose a developer fat fingers a table or a database out of existence? No problem, move the branch to the second before that event happened.
How can I go back in time arbitrarily here? I would have assumed that you can only go to existing snapshots if the underlying method is a COW file system.
This is achieved through our Pageserver. The pageserver ingests streams of WAL, and so contains both snapshots and deltas. This lets us efficiently seek to any LSN by replaying page deltas on top of the nearest snapshot (we call it the GetPage@LSN API).
PostgreSQL writes changes to disk using WAL for consistency. Every WAL record is a set of changes to the PostgreSQL data directory (data files, metadata, ...) that need to be persisted together.
Neon indexes this WAL, and restores pages to the right version by replaying all WAL from the previous page snapshot up to the right version, allowing full point-in-time for all persistent tables in the database.
Calling it "branches" does seem misleading. For instance, would this also work across major PG versions? afaict, it is just not possible to merge two differently versioned postgres-es
Branching in Neon should be interpreted more like the branches seen in graph theory's trees rather than the featureset exposed by git: the whole history of a Neon project is a unidirected graph with a single path between any two points in the history.
> For instance, would this also work across major PG versions
As for multiple major versions: We currently can handle multiple major versions in different tenants on the same pageserver/safekeeper servers, just not for the user's PostgreSQL instance. Major version upgrades (by way of pg_upgrade) are something we're working on, but that's still quite far down the road.
> afaict, it is just not possible to merge two differently versioned postgres-es
Correct, and AFAIK we don't actually advertise anything related to merging histories. If we do, please do tell where, so we can correct that.
If the branches are achieved using a COW file system, how does this part from the blog post work?
> Suppose a developer fat fingers a table or a database out of existence? No problem, move the branch to the second before that event happened.
How can I go back in time arbitrarily here? I would have assumed that you can only go to existing snapshots if the underlying method is a COW file system.