Re: Sequence vs UUID

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Sequence vs UUID
Date: 2023-02-09 17:50:30
Message-ID: CAHyXU0xtK6V5nYGhRDKUHkJCYbLT=jmedQs0qg=oHz9ugxmQjA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Feb 8, 2023 at 5:33 AM Peter J. Holzer <hjp-pgsql(at)hjp(dot)at> wrote:

> On 2023-02-08 14:48:03 +0530, veem v wrote:
> > So wanted to know from experts here, is there really exists any scenario
> in
> > which UUID really cant be avoided?
>
> Probably not. The question is usually not "is this possible" but "does
> this meet the requirements at acceptable cost".
>
>
> > Sequence Number = n*d+m+offset. Where n is the sequence order number, d
> is the
> > dimensions of the multi-master replication, m ranges from 0 to n-1 is the
> > number assigned to each node in the replication, and offset is the
> number to
> > offset the sequence numbers.
>
> Yes, you can do this. In fact, people (including me) have already done
> this.
>
> But it's relatively easy to mess this up:
>
> Firstly, you have to make sure that d is larger than your number of
> (active) replicas will ever be, but still small enough that you will
> never overflow. Probably not a problem with 64 bit sequences (if you set
> d to 1E6, you can still count to 9E12 on each node), but might be a
> problem if you are for some reason limited to 32 bits.
>
> Secondly (and IMHO more importantly) you have to make sure each node
> gets its own unique offset. So this needs to be ensured during
> deployment, but also during migrations, restores from backups and other
> infrequent events.

?? All you have to do is ensure each node has its own unique id, and that
id is involved in sequence generation. This has to be done for other
reasons than id generation, and is a zero effort/risk process.

The id would then contain the identifier of the node that *generated* the
id, rather than the node that contains the id. This is exactly analogous
to strategies that use mac# as part of id prefix for example. Once
generated, it's known unique and you don't have to consider anything.
This is exactly what I do, and there is no interaction with backups,
deployments, migrations, etc. Node expansion does require that each node
requires a unique node id, and that's it.

merlin

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2023-02-09 17:52:27 Re: Using PostgreSQL for service discovery and health-check
Previous Message Adrian Klaver 2023-02-09 17:46:41 Re: Using PostgreSQL for service discovery and health-check