Re: logical changeset generation v3 - comparison to Postgres-R change set format
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Markus Wanner <markus@bluegap.ch>
Cc: pgsql-hackers@postgresql.org
Date: 2012-11-16T14:14:32Z
Lists: pgsql-hackers
Hi, On 2012-11-16 14:46:39 +0100, Markus Wanner wrote: > You may have noticed that there's an additional COID field. This is an > identifier for the transaction that last changed this tuple. Together > with the primary key, it effectively identifies the exact version of a > tuple (during its lifetime, for example before vs after an UPDATE). This > in turn is used by Postgres-R to detect conflicts. Whats the data type of the "COID" in -R? In the patchset the output plugin has enough data to get the old xid and the new xid in the case of updates (not in the case of deletes, but thats a small bug and should be fixable with a single line of code), and it has enough information to extract the primary key without problems. I wonder whether we also should track the xid epoch... > It may be possible to add that to the proposed format as well, for it to > be able to implement a Postgres-R-like algorithm. I don't know the exact Postgres-R algorithm (but I queued reading some papers you referred to when we talked), but I guess what we have in mind is roughly similar - its just not even remotely part of this patchset ;) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Background worker processes
- da07a1e85651 9.3.0 cited
-
Rearrange storage of data in xl_running_xacts.
- 5c11725867ac 9.3.0 cited
-
Basic binary heap implementation.
- 7a2fe9bd0371 9.3.0 cited
-
Embedded list interface
- a66ee69add6e 9.3.0 cited
-
Refactor xlog.c to create src/backend/postmaster/startup.c
- 9aceb6ab3c20 9.2.0 cited