From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(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-12-15 13:44:45 |
Message-ID: | c9f394d0-fbb3-0e69-6f43-f6f396c8b703@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14.12.21 02:31, Tomas Vondra wrote:
> 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.
I can't think of a reason why this might be a problem.
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2021-12-15 13:51:51 | Re: logical decoding and replication of sequences |
Previous Message | Amit Kapila | 2021-12-15 13:20:20 | Re: logical decoding and replication of sequences |