Обсуждение: BUG #19434: adding WHERE to a publication can cause UPDATEs and DELETEs to fail on the source table
BUG #19434: adding WHERE to a publication can cause UPDATEs and DELETEs to fail on the source table
От
PG Bug reporting form
Дата:
The following bug has been logged on the website: Bug reference: 19434 Logged by: Tim McLaughlin Email address: tim@gotab.io PostgreSQL version: 18.3 Operating system: all Description: Adding a WHERE clause to a publication can cause UPDATEs and DELETEs to fail on the source table if the filter columns aren't part of the replica identity. While this is a documented behavior, I do think this is a bug and I'll explain why. The core problem is that REPLICA IDENTITY controls two unrelated things: which columns identify a row on the subscriber, and which old column values get written to WAL. Publication row filters need the second capability but have nothing to do with the first. These two purposes should be separated. The result can a bad failure mode (which I experienced catastrophically): a DBA adds a WHERE clause to a publication — a change that should only affect what gets replicated — and it breaks writes on the publisher. There's no error at DDL time. The failure only appears when the application hits an UPDATE or DELETE, potentially taking down production writes as it did in my case. The current workarounds both have unnecessary costs: - REPLICA IDENTITY FULL writes every column's old value to WAL for every change, increasing WAL volume far beyond what the filter actually needs. - Creating a unique index that includes the filter columns adds storage and maintenance overhead for an index that serves no query purpose. I'd propose that when a publication has a WHERE clause, PostgreSQL automatically includes the referenced columns' old values in WAL without requiring a change to REPLICA IDENTITY. The additional columns being written could be tracked in a new column on pg_publication_rel, making the behavior transparent and inspectable. This would preserve the existing REPLICA IDENTITY for their intended (and semantically sensible) purpose while eliminating a non-obvious way to break a production publisher.
Re: BUG #19434: adding WHERE to a publication can cause UPDATEs and DELETEs to fail on the source table
От
Greg Sabino Mullane
Дата:
I don't think this is really a bug, more of a feature request / optimization. However, I do agree this is an important one. I don't see offhand why we can't append the where list to our existing list of important columns. There would be a few downsides, but none that would be worse than going full replica identity or creating a new index. I'll see about making a proof of concept patch and throwing it on -hackers. Will cc you on that.
Cheers,
Greg
Thanks for the feedback, Greg.
Cheers,
Tim
+1-571-263-1023
On Mon, Mar 23, 2026 at 12:47 PM Greg Sabino Mullane <htamfids@gmail.com> wrote:
I don't think this is really a bug, more of a feature request / optimization. However, I do agree this is an important one. I don't see offhand why we can't append the where list to our existing list of important columns. There would be a few downsides, but none that would be worse than going full replica identity or creating a new index. I'll see about making a proof of concept patch and throwing it on -hackers. Will cc you on that.Cheers,Greg