public inbox for [email protected]  

help / color / mirror / Atom feed

From: Amit Kapila <[email protected]>
To: Tomas Vondra <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Rahila Syed <[email protected]>
Cc: Peter Smith <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Column Filtering in Logical Replication
Date: Wed, 16 Feb 2022 15:35:34 +0530
Message-ID: <CAA4eK1KONbrck=hQTFSFgwio5rqu-82KZba2HLE_AcVa_RWYcQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>

On Wed, Feb 16, 2022 at 5:03 AM Tomas Vondra
<[email protected]> wrote:
>
> Hi,
>
> Here's an updated version of the patch, rebased to current master. Parts
> 0002 and 0003 include various improvements based on review by me and
> another one by Peter Smith [1].
>
> Part 0003 reworks and significantly extends the TAP test, to exercise
> various cases related to changes of replica identity etc. discussed in
> this thread. Some of the tests however still fail, because the behavior
> was not updated - I'll work on that once we agree what the expected
> behavior is.
>
> 1) partitioning with pubviaroot=true
>
> The main set of failures is related to partitions with different replica
> identities and (pubviaroot=true), some of which may be mismatching the
> column list. There are multiple such test cases, depending on how the
> inconsistency is introduced - it may be there from the beginning, the
> column filter may be modified after adding the partitioned table to the
> publication, etc.
>
> I think the expected behavior is to prohibit such cases from happening,
> by cross-checking the column filter when adding the partitioned table to
> publication, attaching a partition or changing a column filter.
>

I feel it is better to follow the way described by Peter E. here [1]
to handle these cases. The row filter patch is also using the same
scheme as that is what we are doing now for Updates/Deletes and it
would be really challenging and much more effort/code to deal with
everything at DDL time. I have tried to explain some of that in my
emails [2][3].

[1] - https://www.postgresql.org/message-id/ca91dc91-80ba-e954-213e-b4170a6160f5%40enterprisedb.com
[2] - https://www.postgresql.org/message-id/CAA4eK1%2Bm45Xyzx7AUY9TyFnB6CZ7_%2B_uooPb7WHSpp7UE%3DYmKg%40ma...
[3] - https://www.postgresql.org/message-id/CAA4eK1%2B1DMkCip9SB3B0_u0Q6fGf-D3vgqQodkLfur0qkL482g%40mail.g...


-- 
With Regards,
Amit Kapila.

view thread (20+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Column Filtering in Logical Replication
  In-Reply-To: <CAA4eK1KONbrck=hQTFSFgwio5rqu-82KZba2HLE_AcVa_RWYcQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox