Re: pg_system_identifier() - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pg_system_identifier()
Date
Msg-id 20130822162019.GC10710@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: pg_system_identifier()  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: pg_system_identifier()  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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.

Not necessarily that exact encoding, but hopefully you get my point.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_system_identifier()
Next
From: Andres Freund
Date:
Subject: Re: pg_system_identifier()