From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | 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 14:30:25 |
Message-ID: | 20150407143025.GC12291@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-04-07 14:37:05 | Re: Replication identifiers, take 4 |
Previous Message | Greg Stark | 2015-04-07 14:04:16 | Re: Column mis-spelling hints vs case folding |