Re: row filtering for logical replication
Euler Taveira <euler@eulerto.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Release cache tuple when no longer needed
- ed0fbc8e5ac9 15.0 landed
-
Add some additional tests for row filters in logical replication.
- ceb57afd3ce1 15.0 landed
-
Fix one of the tests introduced in commit 52e4f0cd47.
- cfb4e209ec15 15.0 landed
-
Allow specifying row filters for logical replication of tables.
- 52e4f0cd472d 15.0 landed
-
Move scanint8() to numutils.c
- cfc7191dfea3 15.0 cited
-
Replace Test::More plans with done_testing
- 549ec201d613 15.0 cited
-
Reduce relcache access in WAL sender streaming logical changes
- 6ce16088bfed 15.0 cited
-
Small cleanups related to PUBLICATION framework code
- c9105dd3660f 15.0 cited
-
Add a view to show the stats of subscription workers.
- 8d74fc96db5f 15.0 cited
-
Allow publishing the tables of schema.
- 5a2832465fd8 15.0 cited
-
Doc: improve documentation of CREATE/ALTER SUBSCRIPTION.
- 1882d6cca161 15.0 cited
-
Add PublicationTable and PublicationRelInfo structs
- 0c6828fa987b 15.0 cited
-
Remove unused argument "txn" in maybe_send_schema().
- 93d573d86571 15.0 cited
-
Add prepare API support for streaming transactions in logical replication.
- 63cf61cdeb7b 15.0 cited
-
Unify PostgresNode's new() and get_new_node() methods
- 201a76183e20 15.0 cited
-
Use l*_node() family of functions where appropriate
- 2b00db4fb0c7 15.0 cited
-
Add support for prepared transactions to built-in logical replication.
- a8fd13cab0ba 15.0 cited
-
Restore the portal-level snapshot after procedure COMMIT/ROLLBACK.
- ef9480509622 11.13 cited
-
Rename a parse node to be more general
- 91d1f2d30210 14.0 landed
-
Remove unused column atttypmod from initial tablesync query
- 4ad31bb2ef25 14.0 landed
-
SEARCH and CYCLE clauses
- 3696a600e229 14.0 cited
On Thu, Feb 17, 2022, at 3:36 AM, Amit Kapila wrote: > As there is a new version, I would like to wait for a few more days > before committing. I am planning to commit this early next week (by > Tuesday) unless others or I see any more things that can be improved. Amit, I don't have additional comments or suggestions. Let's move on. Next topic. :-) > I would once like to mention the replica identity handling of the > patch. Right now, (on HEAD) we are not checking the replica identity > combination at DDL time, they are checked at execution time in > CheckCmdReplicaIdentity(). This patch follows the same scheme and > gives an error at the time of update/delete if the table publishes > update/delete and the publication(s) has a row filter that contains > non-replica-identity columns. We had earlier thought of handling it at > DDL time but that won't follow the existing scheme and has a lot of > complications as explained in emails [1][2]. Do let me know if you see > any problem here? IMO it is not an issue that this patch needs to solve. The conclusion of checking the RI at the DDL time vs execution time is that: * the current patch just follows the same pattern used in the current logical replication implementation; * it is easier to check during execution time (a central point) versus a lot of combinations for DDL commands; * the check during DDL time might eventually break if new subcommands are added; * the execution time does not have the maintenance burden imposed by new DDL subcommands; * we might change the RI check to execute at DDL time if the current implementation imposes a significant penalty in certain workloads. Again, it is material for another patch. Thanks for taking care of a feature that has been discussed for 4 years [1]. [1] https://www.postgresql.org/message-id/CAHE3wggb715X%2BmK_DitLXF25B%3DjE6xyNCH4YOwM860JR7HarGQ%40mail.gmail.com -- Euler Taveira EDB https://www.enterprisedb.com/