Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps

On 10/12/14 04:26, Michael Paquier wrote:
> On Thu, Dec 4, 2014 at 9:26 PM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)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