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  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: "unix_socket_directories" should be GUC_LIST_INPUT?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Prevent printing "next step instructions" in initdb and pg_upgrade