| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | "a(dot)kutepow(at)prodat-sql(dot)de" <a(dot)kutepow(at)prodat-sql(dot)de> |
| Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: BUG #18019: misbehaviour by replication |
| Date: | 2023-07-13 08:21:34 |
| Message-ID: | TYAPR01MB58660F0D9599DA216F9331D4F537A@TYAPR01MB5866.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Dear André,
Thanks for the bug report!
We have reproduced the scenario, and slightly simplified the steps and changed
the table/column names to be more generic. Please see the attached script.
You have a PUBLICATION using a row filter “WHERE (should_replicate IS true)”
When you updated that filter column from TRUE to FALSE, we think you hoped that it would not replicate.
But actually this behaviour is correct according to the documentation describing UPDATE Transformations [1]
Specifically “If the old row satisfies the row filter expression (it was sent to the subscriber) but the new row doesn't, then, from a data consistency perspective the old row should be removed from the subscriber. So the UPDATE is transformed into a DELETE.”
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
| Attachment | Content-Type | Size |
|---|---|---|
| test_rep.sh | application/octet-stream | 1.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | André Kutepow | 2023-07-13 09:03:37 | Re: BUG #18019: misbehaviour by replication |
| Previous Message | Kyotaro Horiguchi | 2023-07-13 07:49:01 | Re: BUG #18019: misbehaviour by replication |