| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Column Filtering in Logical Replication |
| Date: | 2022-01-31 07:13:47 |
| Message-ID: | ca91dc91-80ba-e954-213e-b4170a6160f5@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12.01.22 01:41, Alvaro Herrera wrote:
> I discovered a big hole in this, which is that ALTER PUBLICATION SET
> (publish='insert,update') can add UPDATE publishing to a publication
> that was only publishing INSERTs. It's easy to implement a fix: in
> AlterPublicationOptions, scan the list of tables and raise an error if
> any of them has a column list that doesn't include all the columns in
> the replica identity.
Right now, we are not checking the publication options and the replica
identity combinations at all at DDL time. This is only checked at
execution time in CheckCmdReplicaIdentity(). So under that scheme I
don't think the check you describe is actually necessary. Let the user
set whatever combination they want, and check at execution time if it's
an UPDATE or DELETE command whether the replica identity is sufficient.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Nancarrow | 2022-01-31 07:14:53 | Re: row filtering for logical replication |
| Previous Message | Michael Paquier | 2022-01-31 07:11:48 | Re: make MaxBackends available in _PG_init |