Horton
Menu

Re: Column Filtering in Logical Replication

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Amit Kapila <amit.kapila16@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, Hou, Zhijie/侯 志杰 <houzj.fnst@fujitsu.com>, Rahila Syed <rahilasyed90@gmail.com>, Peter Smith <smithpb2250@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-01-18T10:33:19Z
Lists: pgsql-hackers 
On 15.01.22 04:45, Amit Kapila wrote:
>>> I think another issue w.r.t column filter patch is that even while
>>> creating publication (even for 'insert' publications) it should check
>>> that all primary key columns must be part of published columns,
>>> otherwise, it can fail while applying on subscriber as it will try to
>>> insert NULL for the primary key column.
>>
>> I'm not so sure about the primary key aspects, actually; keep in mind
>> that the replica can have a different table definition, and it might
>> have even a completely different primary key.  I think this part is up
>> to the user to set up correctly; we have enough with just trying to make
>> the replica identity correct.
> 
> But OTOH, the primary key is also considered default replica identity,
> so I think users will expect it to work. You are right this problem
> can also happen if the user defined a different primary key on a
> replica but that is even a problem in HEAD (simple inserts will fail)
> but I am worried about the case where both the publisher and
> subscriber have the same primary key as that works in HEAD.

This would seem to be a departure from the current design of logical 
replication.  It's up to the user to arrange things so that data can be 
applied in general.  Otherwise, if the default assumption is that the 
schema is the same on both sides, then column filtering shouldn't exist 
at all, since that will necessarily break that assumption.

Maybe there could be a strict mode or something that has more checks, 
but that would be a separate feature.  The existing behavior is that you 
can publish anything you want and it's up to you to make sure the 
receiving side can store it.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Doc: Explain about Column List feature.

  2. Doc: fix column list vs. replica identity rules.

  3. Prohibit combining publications with different column lists.

  4. Fix the check to limit sync workers.

  5. Wait for subscription to sync in t/031_column_list.sql

  6. Move prattrs to the pg_publication_rel section in docs

  7. Allow specifying column lists for logical replication

  8. Fix row filters with multiple publications

  9. Fix publish_as_relid with multiple publications

  10. Add some additional tests for row filters in logical replication.

  11. Add index on pg_publication_rel.prpubid

  12. Avoid using DefElemAction in AlterPublicationStmt

  13. Small cleanups related to PUBLICATION framework code

  14. Add PublicationTable and PublicationRelInfo structs

  15. Fix various concurrency issues in logical replication worker launching