Re: Exposing the Xact commit order to the user

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