From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: sequences vs. synchronous replication |
Date: | 2021-12-19 03:03:16 |
Message-ID: | CAA4eK1KN-Pqe1y5w0uXU2Ttn8DK4WfqgwAbCRbcDt4yzQ88wRA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Dec 18, 2021 at 7:24 AM Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>
> while working on logical decoding of sequences, I ran into an issue with
> nextval() in a transaction that rolls back, described in [1]. But after
> thinking about it a bit more (and chatting with Petr Jelinek), I think
> this issue affects physical sync replication too.
>
> Imagine you have a primary <-> sync_replica cluster, and you do this:
>
> CREATE SEQUENCE s;
>
> -- shutdown the sync replica
>
> BEGIN;
> SELECT nextval('s') FROM generate_series(1,50);
> ROLLBACK;
>
> BEGIN;
> SELECT nextval('s');
> COMMIT;
>
> The natural expectation would be the COMMIT gets stuck, waiting for the
> sync replica (which is not running), right? But it does not.
>
How about if we always WAL log the first sequence change in a transaction?
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2021-12-19 05:09:41 | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) |
Previous Message | Maciek Sakrejda | 2021-12-19 00:34:00 | Re: [EXTERNAL] Re: should we document an example to set multiple libraries in shared_preload_libraries? |