Re: Replication Node Identifiers and crashsafe Apply Progress - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Replication Node Identifiers and crashsafe Apply Progress
Date
Msg-id 20131119182006.GA7240@alap2.anarazel.de
Whole thread Raw
In response to Re: Replication Node Identifiers and crashsafe Apply Progress  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Replication Node Identifiers and crashsafe Apply Progress  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2013-11-19 12:47:29 -0500, Robert Haas wrote:
> On Tue, Nov 19, 2013 at 11:57 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > Agreed. As an alternative we could just have a single - probably longer
> > than NAMEDATALEN - string to identify replication progress and rely on
> > the users of the facility to build the identifier automatically
> > themselves using components that are helpful in their system.
> 
> I tend to feel like a generic identifier would be better.  I'm not
> sure why something like a UUID wouldn't be enough, though.
> Arbitrary-length identifiers will be bad for performance, and 128 bits
> ought to be enough for anyone.

That's what I had suggested to some people originally and the response
was, well, somewhat unenthusiastic. It's not that easy to assign them in
a meaningful automated manner. How do you automatically assign a pg
cluster an id?
But yes, maybe the answer is to balk on that part, let the users figure
out what's best, and then only later implement more policy based on that
experience.

WRT performance: I agree that fixed-width identifiers are more
performant, that's why I went for them, but I am not sure it's that
important. The performance sensitive parts should all be done using the
internal id the identifier maps to, not the public one.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: David Johnston
Date:
Subject: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Next
From: Robert Haas
Date:
Subject: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block