Re: logical decoding and replication of sequences

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Petr Jelinek <petr(dot)jelinek(at)enterprisedb(dot)com>
Subject: Re: logical decoding and replication of sequences
Date: 2021-09-23 10:27:17
Message-ID: 482c10c1-b110-819f-b0e7-17549fa2f0dc@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30.07.21 20:26, Tomas Vondra wrote:
> Here's a an updated version of this patch - rebased to current master,
> and fixing some of the issues raised in Peter's review.

This patch needs an update, as various conflicts have arisen now.

As was discussed before, it might be better to present a separate patch
for just the logical decoding part for now, since the replication and
DDL stuff has the potential to conflict heavily with other patches being
discussed right now. It looks like cutting this patch in two should be
doable easily.

I looked through the test cases in test_decoding again. It all looks
pretty sensible. If anyone can think of any other tricky or dubious
cases, we can add them there. It's easiest to discuss these things with
concrete test cases rather than in theory.

One slightly curious issue is that this can make sequence values go
backwards, when seen by the logical decoding consumer, like in the test
case:

+ BEGIN
+ sequence: public.test_sequence transactional: 1 created: 1 last_value:
1, log_cnt: 0 is_called: 0
+ COMMIT
+ sequence: public.test_sequence transactional: 0 created: 0 last_value:
33, log_cnt: 0 is_called: 1
+ BEGIN
+ sequence: public.test_sequence transactional: 1 created: 1 last_value:
4, log_cnt: 0 is_called: 1
+ COMMIT
+ sequence: public.test_sequence transactional: 0 created: 0 last_value:
334, log_cnt: 0 is_called: 1

I suppose that's okay, since it's not really the intention that someone
is concurrently consuming sequence values on the subscriber. Maybe
something for the future. Fixing that would require changing the way
transactional sequence DDL updates these values, so it's not directly
the job of the decoding to address this.

A small thing I found: Maybe the text that test_decoding produces for
sequences can be made to look more consistent with the one for tables.
For example, in

+ BEGIN
+ sequence: public.test_table_a_seq transactional: 1 created: 1
last_value: 1, log_cnt: 0 is_called: 0
+ sequence: public.test_table_a_seq transactional: 1 created: 0
last_value: 33, log_cnt: 0 is_called: 1
+ table public.test_table: INSERT: a[integer]:1 b[integer]:100
+ table public.test_table: INSERT: a[integer]:2 b[integer]:200
+ COMMIT

note how the punctuation is different.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-09-23 10:34:36 Re: Proposal: Save user's original authenticated identity for logging
Previous Message Marcos Pegoraro 2021-09-23 10:22:59 Re: logical replication restrictions