Re: [HACKERS] Logical Replication WIP

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: [HACKERS] Logical Replication WIP
Дата
Msg-id CAMsr+YGou4F9-n+7yMYzNPH2Cih_b=i6ebF+r_fdSKaDyv-XiQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Logical Replication WIP  (Petr Jelinek <petr@2ndquadrant.com>)
Ответы Re: [HACKERS] Logical Replication WIP  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Список pgsql-hackers
On 15 Dec. 2016 18:19, "Petr Jelinek" <petr.jelinek@2ndquadrant.com> wrote:
On 13/12/16 21:42, Peter Eisentraut wrote:
> On 12/10/16 2:48 AM, Petr Jelinek wrote:
>> Attached new version with your updates and rebased on top of the current
>> HEAD (the partitioning patch produced quite a few conflicts).
>
> I have attached a few more "fixup" patches, mostly with some editing of
> documentation and comments and some compiler warnings.
>
> In 0006 in the protocol documentation I have left a "XXX ???" where I
> didn't understand what it was trying to say.
>

Ah so you didn't understand the
> +                Identifies the following TupleData submessage as a key.
> +                This field is optional and is only present if
> +                the update changed the REPLICA IDENTITY index. XXX???

So what happens here is that the update message can contain one or two
out of 3 possible tuple submessages. It always contains 'N' message
which is the new data. Then it can optionally contain 'O' message with
old data if the table has REPLICA IDENTITY FULL (ie, not REPLICA
IDENTITY index like pkey, etc). Or it can include 'K' message that only
contains old data for the columns in the REPLICA IDENTITY index. But if
the REPLICA IDENTITY index didn't change (ie, old and new would be same
for those columns) we simply omit the 'K' message and let the downstream
take the key data from the 'N' message to save space.

Something we forgot to bake into pglogical that might be worth leaving room for here: sending the whole old tuple, with some fields marked as key.

So you can use replica identity pkey or whatever and the downstream knows which are the key fields. But can still transmit the whole old tuple in case the downstream wants it for conflict resolution/logging/etc.

We don't have the logical decoding and wal output for this yet, nor a way of requesting old tuple recording table by table. So all i'm suggesting is leaving room in the protocol.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vladimir Rusinov
Дата:
Сообщение: Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
Следующее
От: Ian Jackson
Дата:
Сообщение: Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraintviolation [and 2 more messages] [and 1 more messages]