Re: Replica Identity check of partition table on subscriber - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Replica Identity check of partition table on subscriber
Date
Msg-id CAA4eK1K7rCa0Hfk3+LdtFqEBrr4r6JjsqJPnqJDa6CeDnzwy3g@mail.gmail.com
Whole thread Raw
In response to Re: Replica Identity check of partition table on subscriber  (Amit Langote <amitlangote09@gmail.com>)
Responses RE: Replica Identity check of partition table on subscriber
Re: Replica Identity check of partition table on subscriber
List pgsql-hackers
On Fri, Jun 10, 2022 at 2:26 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> +logicalrep_partmap_invalidate
>
> I wonder why not call this logicalrep_partmap_update() to go with
> logicalrep_relmap_update()?  It seems confusing to have
> logicalrep_partmap_invalidate() right next to
> logicalrep_partmap_invalidate_cb().
>

I am thinking about why we need to update the relmap in this new
function logicalrep_partmap_invalidate()? I think it may be better to
do it in logicalrep_partition_open() when actually required,
otherwise, we end up doing a lot of work that may not be of use unless
the corresponding partition is accessed. Also, it seems awkward to me
that we do the same thing in this new function
logicalrep_partmap_invalidate() and then also in
logicalrep_partition_open() under different conditions.

One more point about the 0001, it doesn't seem to have a test that
validates logicalrep_partmap_invalidate_cb() functionality. I think
for that we need to Alter the local table (table on the subscriber
side). Can we try to write a test for it?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: David Zhang
Date:
Subject: Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths
Next
From: Thomas Munro
Date:
Subject: Re: Collation version tracking for macOS