On 5/27/2010 9:59 AM, Greg Stark wrote:
> On Wed, May 26, 2010 at 5:38 PM, Greg Stark <gsstark@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 <JanWieck@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