From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, Petr Jelinek <petr(at)2ndquadrant(dot)com> |
Cc: | 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 15:57:27 |
Message-ID: | 5523FE67.5020900@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/7/15 9:30 AM, Andres Freund wrote:
> On 2015-03-28 23:50:20 +0100, Petr Jelinek wrote:
>> 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?
>
> As the same reason exists for oids, just somewhat less likely, I don't
> see it as a reason for much. It's really not that hard to get oid
> conflicts once your server has lived for a while. As soon as the oid
> counter has wrapped around once, it's not unlikely to have
> conflicts. And with temp tables (or much more extremely WITH OID tables)
> and such it's not that hard to reach that point. The only material
> difference this makes is that it's much easier to notice the problem
> during development.
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.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-04-07 15:58:18 | Re: Replication identifiers, take 4 |
Previous Message | Stephen Frost | 2015-04-07 15:21:49 | Re: Row security violation error is misleading |