Re: pg_system_identifier() - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_system_identifier()
Date
Msg-id 20130822163059.GI17006@awork2.anarazel.de
Whole thread Raw
In response to Re: pg_system_identifier()  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pg_system_identifier()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_system_identifier()
Next
From: Tom Lane
Date:
Subject: Re: pg_system_identifier()