From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PG DOCS - logical replication filtering |
Date: | 2022-03-04 03:47:56 |
Message-ID: | CAHut+PtHQd69shrMU4vtJ10QqSR7wDQvaOWWoeXdLFaLJcn+Aw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 3, 2022 at 2:15 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Mar 2, 2022 at 8:00 PM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> >
> > On 02.03.22 05:47, Peter Smith wrote:
> > > This patch introduces a new "Filtering" page to give a common place
> > > where all kinds of logical replication filtering can be described.
> > > (e.g. It is envisaged that a "Column Filters" section can be added
> > > sometime in the future).
> >
> > The pending feature to select a subset of table columns to replicate is
> > not "column filtering". The thread might still be still called that,
> > but we have changed the patch to not use that terminology.
> >
> > Filtering is a dynamic action based on actual values. The row filtering
> > feature does that. The column list feature is a static DDL-time
> > configuration. It is no more filtering than specifying a list of tables
> > in a publication is table filtering.
> >
> > So please consider organizing the documentation differently to not
> > create this confusion.
> >
>
> +1. I think Row Filters can directly be a section just before
> Conflicts on the logical replication page [1].
Done as suggested in v3. [1]
>
> Some comments on the patch:
> 1. I think we can extend/add the example to have filters on more than
> one table. This has been noticed multiple times during development
> that people are not very clear on it.
Added example in v3 [1]
> 2. I think we can add an example or two for row filters actions (like
> Insert, Update).
Added examples of INSERT and UPDATE in v3 [1]
> 3.
> Publications can choose to limit the changes they produce to
> any combination of <command>INSERT</command>, <command>UPDATE</command>,
> - <command>DELETE</command>, and <command>TRUNCATE</command>,
> similar to how triggers are fired by
> - particular event types. By default, all operation types are replicated.
> + <command>DELETE</command>, and <command>TRUNCATE</command> by using
> + <quote>operation filters</quote>.
>
> By this, one can imply that row filters are used for Truncate as well
> but that is not true. I know that that patch later specifies that "Row
> filters have no effect for <command>TRUNCATE</command> commands." but
> the above modification is not very clear.
>
Fixed in v3 [1]. Restored original text, and added a note about row filters.
Kind Regards,
Peter Smith.
Fujitsu Australia.
From | Date | Subject | |
---|---|---|---|
Next Message | Japin Li | 2022-03-04 04:18:29 | Re: Doc about how to set max_wal_senders when setting minimal wal_level |
Previous Message | Peter Smith | 2022-03-04 03:41:58 | Re: PG DOCS - logical replication filtering |