Re: Replication Node Identifiers and crashsafe Apply Progress

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Steve Singer <steve(at)ssinger(dot)info>
Subject: Re: Replication Node Identifiers and crashsafe Apply Progress
Date: 2013-11-19 18:20:06
Message-ID: 20131119182006.GA7240@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-11-19 18:20:47 Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Previous Message Atri Sharma 2013-11-19 18:18:28 Re: stats for network traffic WIP