Re: deferred primary key and logical replication
От | Amit Kapila |
---|---|
Тема | Re: deferred primary key and logical replication |
Дата | |
Msg-id | CAA4eK1LuoNACjV5vk-w4BKz2cV-HqmBnoZxQ1AixJ5WCraDNGg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: deferred primary key and logical replication (Euler Taveira <euler.taveira@2ndquadrant.com>) |
Ответы |
Re: deferred primary key and logical replication
|
Список | pgsql-hackers |
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. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: