On 5/27/2010 9:59 AM, Greg Stark wrote:
On Wed, May 26, 2010 at 5:38 PM, Greg Stark <gsst...@mit.edu> wrote:
How about just API generalities? Like, where do you need this data, on
the master or on the slave? Would PGXC like it on the transaction
coordinator?
What question do you need to answer, do you need to pull out sets of
commits in certain ranges or look up specific transaction ids and find
out when they committed? Or do you only need to answer which of two
transaction ids committed first?
This thread has been hard to follow for me. Were any of these
questions answered?
Yes.
On 5/26/2010 4:49 PM, Jan Wieck wrote:
On 5/26/2010 12:38 PM, Greg Stark wrote:
> On Wed, May 26, 2010 at 5:10 PM, Jan Wieck <janwi...@yahoo.com> wrote:
>> ... but to answer that request, actually I don't even think we should be
>> discussing API specifics.
>>
>
> How about just API generalities? Like, where do you need this data, on
> the master or on the slave? Would PGXC like it on the transaction
> coordinator?
>
> What question do you need to answer, do you need to pull out sets of
> commits in certain ranges or look up specific transaction ids and find
> out when they committed? Or do you only need to answer which of two
> transaction ids committed first?
The question I want answered is
"what was the order and xid of the next 0..n transactions, that
committed after transaction X?"
Preferably I would avoid scanning the entire available WAL just to get
the next n xid's to process.
The proposal assigned a unique serial number (file segment and position
driven) to each xid and used that for the ordering as well as
identification of the last known transaction. That is certainly a
premature implementation detail.
In this implementation it wouldn't even matter if a transaction that was
recorded actually never made it because it crashed before the WAL flush.
It would be reported by this "commit order" feature, but there would be
no traces of whatever it did to be found inside the DB, so that anomaly
is harmless.
Jan
-- Anyone who trades liberty for security deserves neither liberty nor
security. -- Benjamin Franklin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
