On 2014-06-23 10:09:49 -0400, Robert Haas wrote:
> On Wed, Jun 18, 2014 at 12:46 PM, Andres Freund <and...@2ndquadrant.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to