Horton

Re: logical decoding and replication of sequences

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Petr Jelinek <petr.jelinek@enterprisedb.com>
Date: 2021-12-15T13:20:20Z
Lists: pgsql-hackers 
On Tue, Dec 14, 2021 at 7:02 AM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
> Hi,
>
> here's an updated version of the patches, dealing with almost all of the
> issues (at least in the 0001 and 0002 parts). The main changes:
>
> 1) I've removed the  'created' flag from fill_seq_with_data, as
> discussed. I don't think it's needed by any of the parts (not even 0003,
> AFAICS). We still need it in xl_seq_rec, though.
>
> 2) GetCurrentTransactionId() added to sequence.c are called only with
> wal_level=logical, to minimize the overhead.
>
>
> There's still one remaining problem, that I already explained in [1].
> The problem is that with this:
>
>   BEGIN;
>   SELECT nextval('s') FROM generate_series(1,100);
>   ROLLBACK;
>
>
> The root cause is that pg_current_wal_lsn() uses the LogwrtResult.Write,
> which is updated by XLogFlush() - but only in RecordTransactionCommit.
> Which makes sense, because only the committed stuff is "visible".
>
> But the non-transactional behavior of sequence decoding disagrees with
> this, because now some of the changes from aborted transactions may be
> replicated. Which means the wait_for_catchup() ends up not waiting for
> the sequence change to be replicated. This is an issue for tests in
> patch 0003, at least.
>
> My concern is this actually affects other places waiting for things
> getting replicated :-/
>

By any chance, will this impact synchronous replication as well which
waits for commits to be replicated?

How is this patch dealing with prepared transaction case where at
prepare we will send transactional changes and then later if rollback
prepared happens then the publisher will rollback changes related to
new relfilenode but subscriber would have already replayed the updated
seqval change which won't be rolled back?

--
With Regards,
Amit Kapila.

Commits

  1. Fix cache invalidation bug in recovery_prefetch.

  2. Revert "Logical decoding of sequences"

  3. Minor improvements in sequence decoding code and docs

  4. Handle sequences in preprocess_pubobj_list

  5. Update tab-completion for CREATE PUBLICATION with sequences

  6. Add decoding of sequences to built-in replication

  7. Stabilize test_decoding touching with sequences

  8. Call ReorderBufferProcessXid from sequence_decode

  9. Add decoding of sequences to test_decoding

  10. Replace Test::More plans with done_testing

  11. Logical decoding of sequences

  12. Respect permissions within logical replication.