From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Markus Wanner <markus(at)bluegap(dot)ch> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: logical changeset generation v3 - comparison to Postgres-R change set format |
Date: | 2012-11-16 14:14:32 |
Message-ID: | 20121116141432.GB6505@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2012-11-16 14:22:22 | Re: Proposal for Allow postgresql.conf values to be changed via SQL |
Previous Message | Robert Haas | 2012-11-16 14:12:21 | Re: tuplesort memory usage: grow_memtuples |