On 2013-08-22 12:20:19 -0400, Alvaro Herrera wrote: > Andres Freund wrote: > > On 2013-08-22 12:06:03 -0400, Tom Lane wrote: > > > > I agree that if we have a function named pg_system_identifier(), it ought > > > to return the same value that pg_controldata prints under that name. > > > But that doesn't really answer any questions about how that value is > > > obtained. I think the question on the table right now is whether we like > > > the way that value behaves, in the context of a user-visible system ID. > > > In particular, do we want to think about changing things so tha > > > (1) a slave has a different ID than the master, and/or > > > > We currently use the system identifier to know that we're replicating > > between the same/compatible systems (c.f. libpqwalreceiver.c: > > libpqrcv_identify_system()), so I don't think a change of definition > > like that is realistic. > > We could split the value; make sure that the first, way, 96 bits are > identical in master and slaves (and change the code to only compare > those bits); but the last 32 bits are system specific and cannot appear > twice in the same replica network. Also, perhaps we should reserve the > last (say) 4 bits, so that 0000 means master and 0001 means standby (it > changes on promotion), and the rest of the values are reserved for > future use.
Why? This seems to be making a simple thing into something way much more complex? Imo this proposal is about further exposing an already existing, already exposed (via pg_controldata, via replication protocol) variable, not more. It seems better to make sure the other datapoints are *also* exposed if they aren't yet. Some are: * port (SHOW port;) * standby/primary (SELECT pg_is_in_recovery();) Some are not easily: * system identifier (pg_controldata, replication protocol) * current timeline identifier (pg_controldata, replication protocol) * host identifier/hostname (which actually is hard) Greetings, Andres Freund -- Andres Freund 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