Re: pg_system_identifier()

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_system_identifier()
Date: 2013-08-22 16:30:59
Message-ID: 20130822163059.GI17006@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-08-22 16:37:36 Re: pg_system_identifier()
Previous Message Andres Freund 2013-08-22 16:25:00 Re: pg_system_identifier()