Re: deferred primary key and logical replication

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: deferred primary key and logical replication
Date: 2020-11-23 21:34:56
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 27.10.2020 13:46, Amit Kapila wrote:
> On Sun, Oct 25, 2020 at 9:39 PM Euler Taveira
> <euler(dot)taveira(at)2ndquadrant(dot)com> wrote:
>> On Mon, 5 Oct 2020 at 08:34, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>> On Mon, May 11, 2020 at 2:41 AM Euler Taveira
>>> <euler(dot)taveira(at)2ndquadrant(dot)com> wrote:
>>>> Hi,
>>>> While looking at an old wal2json issue, I stumbled on a scenario that a table
>>>> with a deferred primary key is not updatable in logical replication. AFAICS it
>>>> has been like that since the beginning of logical decoding and seems to be an
>>>> oversight while designing logical decoding.
>>> I am not sure if it is an oversight because we document that the index
>>> must be non-deferrable, see "USING INDEX records the old values of the
>>> columns covered by the named index, which must be unique, not partial,
>>> not deferrable, and include only columns marked NOT NULL." in docs
>>> [1].
>> Inspecting this patch again, I forgot to consider that RelationGetIndexList()
>> is called by other backend modules. Since logical decoding deals with finished
>> transactions, it is ok to use a deferrable primary key.
> But starting PG-14, we do support logical decoding of in-progress
> transactions as well.
Commitfest entry status update.
As far as I see, this patch needs some further work, so I move it to
"Waiting on author".
Euler, are you going to continue working on it?

Anastasia Lubennikova
Postgres Professional:
The Russian Postgres Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2020-11-23 21:58:34 Re: PATCH: Batch/pipelining support for libpq
Previous Message Alvaro Herrera 2020-11-23 21:28:02 Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)