Re: logical changeset generation v3 - comparison to Postgres-R change set format
Markus Wanner <markus@bluegap.ch>
From: Markus Wanner <markus@bluegap.ch>
To: Hannu Krosing <hannu@2ndQuadrant.com>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Date: 2012-11-17T17:41:39Z
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Background worker processes
- da07a1e85651 9.3.0 cited
-
Rearrange storage of data in xl_running_xacts.
- 5c11725867ac 9.3.0 cited
-
Basic binary heap implementation.
- 7a2fe9bd0371 9.3.0 cited
-
Embedded list interface
- a66ee69add6e 9.3.0 cited
-
Refactor xlog.c to create src/backend/postmaster/startup.c
- 9aceb6ab3c20 9.2.0 cited