Re: logical decoding and replication of sequences, take 2
Jonathan S. Katz <jkatz@postgresql.org>
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>,
vignesh C <vignesh21@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date: 2023-02-26T19:11:53Z
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 2/23/23 7:56 AM, Tomas Vondra wrote: > On 2/22/23 18:04, Jonathan S. Katz wrote: >> On 2/22/23 5:02 AM, Tomas Vondra wrote: >>> >> Interestingly, in systems that tend to have higher rates of failover >> (I'm thinking of a few distributed systems), this may cause int4 >> sequences to exhaust numbers slightly (marginally?) more quickly. Likely >> not too big of an issue, but something to keep in mind. >> > > IMHO the number of systems that would work fine with int4 sequences but > this change results in the sequences being "exhausted" too quickly is > indistinguishable from 0. I don't think this is an issue. I agree it's an edge case. I do think it's a number greater than 0, having seen some incredibly flaky setups, particularly in distributed systems. I would not worry about it, but only mentioned it to try and probe edge cases. >>> Well, yeah. We don't support active-active logical replication (at least >>> not with the built-in). You can easily get into similar issues without >>> sequences. >> >> The "origin=none" feature lets you replicate tables bidirectionally. >> While it's not full "active-active", this is a starting point and a >> feature for v16. We'll definitely have users replicating data >> bidirectionally with this. >> > > Well, then the users need to use some other way to generate IDs, not > local sequences. Either some sort of distributed/global sequence, UUIDs > or something like that. [snip] >> In any case, we should update the restrictions in [2] to state: while >> sequences can be replicated, there is additional work required if you >> are bidirectionally replicating tables that use sequences, esp. if used >> in a PK or a constraint. We can provide alternatives to how a user could >> set that up, i.e. not replicates the sequences or do something like in [3]. >> > > I agree. I see this as mostly a documentation issue. Great. I agree that users need other mechanisms to generate IDs, but we should ensure we document that. If needed, I'm happy to help with the docs here. Thanks, Jonathan