Re: Replication identifiers, take 4

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Steve Singer <steve(at)ssinger(dot)info>, <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: Replication identifiers, take 4
Date: 2015-04-07 22:39:32
Message-ID: 55245CA4.5050306@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/7/15 10:58 AM, Andres Freund wrote:
>> Why not just create a sequence? I suspect it may not be as fast to assign as
>> an OID, but it's not like you'd be doing this all the time.
>
> What does that have to do with the thread?

The original bit was...

> And finally I have issue with how the new identifiers are allocated.
> Currently, if you create identifier 'foo', remove identifier 'foo' and
> create identifier 'bar', the identifier 'bar' will have same id as the old
> 'foo' identifier. This can be problem because the identifier id is used as
> origin of the data and the replication solution using the replication
> identifiers can end up thinking that data came from node 'bar' even though
> they came from the node 'foo' which no longer exists. This can have bad
> effects for example on conflict detection or debugging problems with
> replication.
>
> Maybe another reason to use standard Oids?

Wasn't the reason for using OIDs so that we're not doing the equivalent
of max(identifier) + 1?

Perhaps I'm just confused...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-04-07 22:42:34 Re: New error code to track unsupported contexts
Previous Message Jim Nasby 2015-04-07 22:36:31 Re: Support UPDATE table SET(*)=...