Re: deferred primary key and logical replication - Mailing list pgsql-hackers

From Anastasia Lubennikova
Subject Re: deferred primary key and logical replication
Date
Msg-id 95cc5b49-f2da-e282-ce10-aecbab041ace@postgrespro.ru
Whole thread Raw
In response to Re: deferred primary key and logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: deferred primary key and logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 27.10.2020 13:46, Amit Kapila wrote:
> On Sun, Oct 25, 2020 at 9:39 PM Euler Taveira
> <euler.taveira@2ndquadrant.com> wrote:
>> On Mon, 5 Oct 2020 at 08:34, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>> On Mon, May 11, 2020 at 2:41 AM Euler Taveira
>>> <euler.taveira@2ndquadrant.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: http://www.postgrespro.com
The Russian Postgres Company




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
Next
From: "Daniel Verite"
Date:
Subject: Re: PATCH: Batch/pipelining support for libpq