Re: replication identifier format - Mailing list pgsql-hackers

From Andres Freund
Subject Re: replication identifier format
Date
Msg-id 20140618164628.GM3115@awork2.anarazel.de
Whole thread Raw
In response to Re: Set new system identifier using pg_resetxlog  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: replication identifier format  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2014-06-18 12:36:13 -0400, Robert Haas wrote:
> > I actually don't think any of the discussions I was involved in had the
> > externally visible version of replication identifiers limited to 16bits?
> > If you are referring to my patch, 16bits was just the width of the
> > *internal* name that should basically never be looked at. User visible
> > replication identifiers are always identified by an arbitrary string -
> > whose format is determined by the user of the replication identifier
> > facility. *BDR* currently stores the system identifer, the database id
> > and a name in there - but that's nothing core needs to concern itself
> > with.
> 
> I don't think you're going to be able to avoid users needing to know
> about those IDs.  The configuration table is going to have to be the
> same on all nodes, and how are you going to get that set up without
> those IDs being user-visible?

Why? Users and other systems only ever see the external ID. Everything
leaving the system is converted to the external form. The short id
basically is only used in shared memory and in wal records. For both
using longer strings would be problematic.

In the patch I have the user can actually see them as they're stored in
pg_replication_identifier, but there should never be a need for that.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: delta relations in AFTER triggers
Next
From: Tom Lane
Date:
Subject: Re: Is analyze_new_cluster.sh still useful?