Re: Logical Replication of sequences
Peter Smith <smithpb2250@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: Add documentation for sequence synchronization.
- 55cefadde874 19 (unreleased) landed
-
Remove unused assignment in CREATE PUBLICATION grammar.
- bfb7419b0bbe 19 (unreleased) landed
-
Add seq_sync_error_count to subscription statistics.
- f6a4c498dcf6 19 (unreleased) landed
-
Fix few issues in commit 5509055d69.
- 5a4eba558aa7 19 (unreleased) landed
-
Add sequence synchronization for logical replication.
- 5509055d6956 19 (unreleased) landed
-
Add worker type argument to logical replication worker functions.
- 3e8e05596a02 19 (unreleased) landed
-
Introduce "REFRESH SEQUENCES" for subscriptions.
- f0b3573c3aac 19 (unreleased) landed
-
Refactor logical worker synchronization code into a separate file.
- 41c674d2e31e 19 (unreleased) landed
-
Standardize use of REFRESH PUBLICATION in code and messages.
- 2436b8c047ff 19 (unreleased) landed
-
Add "ALL SEQUENCES" support to publications.
- 96b378497346 19 (unreleased) landed
-
Expose sequence page LSN via pg_get_sequence_data.
- b93172ca59f4 19 (unreleased) landed
-
Resume conflict-relevant data retention automatically.
- 0d48d393d465 19 (unreleased) cited
-
Post-commit review fixes for 228c370868.
- 1f7e9ba3ac4e 19 (unreleased) cited
-
Generate GUC tables from .dat file
- 63599896545c 19 (unreleased) cited
Attachments
- PS_NITPICKS_20240723_SEQ_0002.txt (text/plain)
Here are some review comments for patch v20240720-0002. ====== 1. Commit message: 1a. The commit message is stale. It is still referring to functions and views that have been moved to patch 0003. 1b. "ALL SEQUENCES" is not a command. It is a clause of the CREATE PUBLICATION command. ====== doc/src/sgml/ref/create_publication.sgml nitpick - publication name in the example /allsequences/all_sequences/ ====== src/bin/psql/describe.c 2. describeOneTableDetails Although it's not the fault of this patch, this patch propagates the confusion of 'result' versus 'res'. Basically, I did not understand the need for the variable 'result'. There is already a "PGResult *res", and unless I am mistaken we can just keep re-using that instead of introducing a 2nd variable having almost the same name and purpose. ~ nitpick - comment case nitpick - rearrange comment ====== src/test/regress/expected/publication.out (see publication.sql) ====== src/test/regress/sql/publication.sql nitpick - tweak comment ====== Kind Regards, Peter Smith. Fujitsu Australia