Re: sequences vs. synchronous replication
От | Amit Kapila |
---|---|
Тема | Re: sequences vs. synchronous replication |
Дата | |
Msg-id | CAA4eK1KN-Pqe1y5w0uXU2Ttn8DK4WfqgwAbCRbcDt4yzQ88wRA@mail.gmail.com обсуждение исходный текст |
Ответ на | sequences vs. synchronous replication (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Список | pgsql-hackers |
On Sat, Dec 18, 2021 at 7:24 AM Tomas Vondra <tomas.vondra@enterprisedb.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.
В списке pgsql-hackers по дате отправления: