3 ms·

(Postgres hacker @ Neon) PostgreSQL writes changes to disk using WAL for consistency. Every WAL record is a set of changes to the PostgreSQL data directory (da

(Postgres hacker @ Neon) 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.

leftcenterright 3y ago
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
- mattashii 3y ago
  > Calling it "branches" does seem misleading. 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.
- vendiddy 3y ago
  We use NeonDB in production and I the use of the term "branching" intuitive. We can branch off the main database to test things out, and periodically reset the branch to its parent. There are some points where the analogy doesn't quite work, but what should they call it instead?

leftcenterright 3y ago

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

mattashii 3y ago
> Calling it "branches" does seem misleading. 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.
vendiddy 3y ago
We use NeonDB in production and I the use of the term "branching" intuitive. We can branch off the main database to test things out, and periodically reset the branch to its parent. There are some points where the analogy doesn't quite work, but what should they call it instead?