Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps
Date
Msg-id 548860B6.50705@2ndquadrant.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps  (Petr Jelinek <petr@2ndquadrant.com>)
List pgsql-hackers
On 10/12/14 04:26, Michael Paquier wrote:
> On Thu, Dec 4, 2014 at 9:26 PM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> Yeah, it was raised. I don't think it was really addressed. There was
>> lengthy discussion on whether to include LSN, node id, and/or some other
>> information, but there was no discussion on:
>>
>> * What is a node ID?
>> * How is it used?
>> * Who assigns it?
>>
>> etc.
>>
>> None of those things are explained in the documentation nor code comments.
>>
>> The node ID sounds suspiciously like the replication identifiers that have
>> been proposed a couple of times. I don't remember if I like replication
>> identifiers or not, but I'd rather discuss that issue explicitly and
>> separately. I don't want the concept of a replication/node ID to fly under
>> the radar like this.

Replication identifiers are bigger thing but yes there is overlap as the 
nodeid itself makes it possible to implement replication identifiers 
outside of core if needed.

>>
>>>> What would the SQL API look like, and what would it be used for?
>>>
>>>
>>> It would probably mirror the C one, from my POV it's not needed but
>>> maybe some replication solution would prefer to use this without having
>>> to write C components...
>>
>>
>> I can't comment on that, because without any documentation, I don't even
>> know what the C API is.
>>
>> BTW, why is it OK that the node-ID of a commit is logged as a separate WAL
>> record, after the commit record? That means that it's possible that a
>> transaction commits, but you crash just before writing the SETTS record, so
>> that after replay the transaction appears committed but with the default
>> node ID.
>>
>> (Maybe that's OK given the intended use case, but it's hard to tell without
>> any documentation. See a pattern here? ;-) )

This is actually good point, it's not OK to have just commit record but 
no nodeid record if nodeid was set.

>
> Could it be possible to get a refresh on that before it bitrots too
> much or we'll simply forget about it? In the current state, there is
> no documentation able to explain what is the point of the nodeid
> stuff, how to use it and what use cases it is aimed at. The API in
> committs.c should as well be part of it. If that's not done, I think
> that it would be fair to remove this portion and simply WAL-log the
> commit timestamp its GUC is activated.

I have this on my list so it's not being forgotten and I don't see it 
bitrotting unless we are changing XLog api again. I have bit busy 
schedule right now though, can it wait till next week? - I will post 
some code documentation patches then.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: advance local xmin more aggressively
Next
From: Heikki Linnakangas
Date:
Subject: GiST kNN search queue (Re: KNN-GiST with recheck)