Re: deferred primary key and logical replication
От | Anastasia Lubennikova |
---|---|
Тема | Re: deferred primary key and logical replication |
Дата | |
Msg-id | 95cc5b49-f2da-e282-ce10-aecbab041ace@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: deferred primary key and logical replication (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: deferred primary key and logical replication
|
Список | 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 по дате отправления: