On 10/12/14 04:26, Michael Paquier wrote:
On Thu, Dec 4, 2014 at 9:26 PM, Heikki Linnakangas
<hlinnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
