Re: logical decoding and replication of sequences

From: Andres Freund <andres(at)anarazel(dot)de>
To: Hannu Krosing <hannuk(at)google(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, 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-11-23 01:01:14
Message-ID: 20211123010114.5jdp35p7p5cuzwsl@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-09-25 22:05:43 +0200, Hannu Krosing wrote:
> If our aim is just to make sure that all user-visible data in
> *transactional* tables is consistent with sequence state then one
> very much simplified approach to this could be to track the results of
> nextval() calls in a transaction at COMMIT put the latest sequence
> value in WAL (or just track the sequences affected and put the latest
> sequence state in WAL at commit which needs extra read of sequence but
> protects against race conditions with parallel transactions which get
> rolled back later)

I think this is a bad idea. It's architecturally more complicated and prevents
use cases because sequence values aren't guaranteed to be as new as on the
original system. You'd need to track all sequence use somehow *even if there
is no relevant WAL generated* in a transaction. There's simply no evidence of
sequence use in a transaction if that transaction uses a previously logged
sequence value.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2021-11-23 01:06:01 PG docs - CREATE PUBLICATION publish_via_partition_root
Previous Message Mark Dilger 2021-11-23 00:21:42 Re: Granting SET and ALTER SYSTE privileges for GUCs