Re: replication identifier format

On 2014-06-23 10:09:49 -0400, Robert Haas wrote:
> On Wed, Jun 18, 2014 at 12:46 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > 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.
>
> Hmm, so there's no requirement that the short IDs are consistent
> across different clusters that are replication to each other?

Nope. That seemed to be a hard requirement in the earlier discussions we
had (~2 years ago).

> If
> that's the case, that might address my concern, but I'd probably want
> to go back through the latest patch and think about it a bit more.

I'll send out a new version after I'm finished with the newest atomic
ops patch.

Greetings,

Andres Freund

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