Re: pg_system_identifier() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_system_identifier()
Date
Msg-id 15653.1377189456@sss.pgh.pa.us
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>)
Re: pg_system_identifier()  (Hannu Krosing <hannu@2ndQuadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-08-22 12:20:19 -0400, Alvaro Herrera wrote:
>> 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.

Agreed, this seems like overloading the identifier too much.  Currently we
consider it an 8-byte value with unspecified internal structure, and I
think we should probably maintain that approach rather than defining
APIs that assume it can be subdivided.  For one thing, reducing the width
of the "unique" part increases our risk of chance collisions.

Do we have a reliable way of generating a unique identifier for each slave
(independently of how that might be exposed)?
        regards, tom lane



pgsql-hackers by date:

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