On 2013-08-22 12:06:03 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-08-22 08:45:38 -0700, Josh Berkus wrote:
> >> However, given that the value is the same for all servers in a
> >> replication set, are we sure we want to call it system_identifier? Is
> >> there a better name?
>
> > Given it's been named that and visible via pg_controldata for years I am
> > against introducing confusion by renaming it.
>
> 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.
> (2) a slave's ID changes on promotion to master.
We also cannot change the identifier here, because then other standbys
won't be able to follow the promotion because the identifier doesn't
match anymore
But essentially we already have something like that by the combination
of system identifier and timeline id. Admittedly there's the weakness
that the timelineid can increase the same on several machines in the
cluster but that's a weakness we ought to fix sometime independent of
this.
So maybe the answer is to also expose the current timeline?
An alternative would be to have a pg_controldata_values() SRF...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
