Re: logical decoding and replication of sequences, take 2
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Christophe Pettus <xof@thebuild.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Dilip Kumar
<dilipbalaut@gmail.com>, "Hayato Kuroda (Fujitsu)"
<kuroda.hayato@fujitsu.com>, "Zhijie Hou (Fujitsu)"
<houzj.fnst@fujitsu.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Masahiko Sawada <sawada.mshk@gmail.com>,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2023-12-21T13:17:29Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Migrate logical slots to the new node during an upgrade.
- 29d0a77fa660 17.0 cited
-
Make test_decoding ddl.out shorter
- d6677b93c79b 17.0 landed
- c5c5832600e9 14.9 landed
- b1dc946eee3d 16.0 landed
- 3bb8b9342f8a 15.4 landed
-
Fix snapshot handling in logicalmsg_decode
- 949ac32e1267 15.3 landed
- 8b9cbd42b61f 14.8 landed
- 4df581fa0f4b 13.11 landed
- 497f863f0598 12.15 landed
- 8de91ebf2ac1 11.20 landed
- 7fe1aa991b62 16.0 landed
-
doc: Adjust a few more references to "postmaster"
- 17e72ec45d31 16.0 cited
-
Revert "Logical decoding of sequences"
- 2c7ea57e56ca 15.0 cited
On 12/19/23 13:54, Christophe Pettus wrote: > Hi, > > I wanted to hop in here on one particular issue: > >> On Dec 12, 2023, at 02:01, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: >> - desirability of the feature: Random IDs (UUIDs etc.) are likely a much >> better solution for distributed (esp. active-active) systems. But there >> are important use cases that are likely to keep using regular sequences >> (online upgrades of single-node instances, existing systems, ...). > > +1. > > Right now, the lack of sequence replication is a rather large > foot-gun on logical replication upgrades. Copying the sequences > over during the cutover period is doable, of course, but: > > (a) There's no out-of-the-box tooling that does it, so everyone has > to write some scripts just for that one function. > > (b) It's one more thing that extends the cutover window. > I agree it's an annoying gap for this use case. But if this is the only use cases, maybe a better solution would be to provide such tooling instead of adding it to the logical decoding? It might seem a bit strange if most data is copied by replication directly, while sequences need special handling, ofc. > I don't think it is a good idea to make it mandatory: for example, > there's a strong use case for replicating a table but not a sequence > associated with it. But it's definitely a missing feature in > logical replication. I don't think the plan was to make replication of sequences mandatory, certainly not with the built-in replication. If you don't add sequences to the publication, the sequence changes will be skipped. But it still needs to be part of the decoding, which adds overhead for all logical decoding uses, even if the sequence changes end up being discarded. That's somewhat annoying, especially considering sequences are fairly common part of the WAL stream. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company