From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: logical changeset generation v3 - comparison to Postgres-R change set format |
Date: | 2012-11-17 17:41:39 |
Message-ID: | 50A7CC53.6060001@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu,
On 11/17/2012 03:40 PM, Hannu Krosing wrote:
> On 11/17/2012 03:00 PM, Markus Wanner wrote:
>> On 11/17/2012 02:30 PM, Hannu Krosing wrote:
>>> Is it possible to replicate UPDATEs and DELETEs without a primary key in
>>> PostgreSQL-R
>> No. There must be some way to logically identify the tuple.
> It can be done as selecting on _all_ attributes and updating/deleting
> just the first matching row
>
> create cursor ...
> select from t ... where t.* = (....)
> fetch one ...
> delete where current of ...
That doesn't sound like it could possibly work for Postgres-R. At least
not when there can be multiple rows with all the same attributes, i.e.
without a unique key constraint over all columns.
Otherwise, some nodes could detect two concurrent UPDATES as a conflict,
while other nodes select different rows and don't handle it as a conflict.
Regards
Markus Wanner
From | Date | Subject | |
---|---|---|---|
Next Message | Karl O. Pinc | 2012-11-17 18:02:46 | Re: Add big fat caution to pg_restore docs regards partial db restores |
Previous Message | Karl O. Pinc | 2012-11-17 17:33:04 | Re: Doc patch, put pg_temp into the documentation's index |