Hi Amit,
There seem to be different interpretations of your comment.
I understood it as suggesting that we should show a WARNING when adding a
partition or parent table that has unsupported descendant tables.
I would greatly appreciate some clarification on this point. Thanks a lot.
Regards,
Ar
Hello Amit,
Yes, That's my understanding as well.
> The behavior should be the same for both partition and inherited tables.
I'm planning to tackle partition tables in the follow-up patch. What do you
think?
Thanks,
Arun
On Tue, 16 Dec 2025 at 15:04, Amit Kapila wrote:
> On Tue, Dec 16, 2025
Thank you, Zhijie and Euler, for your thoughts.
I’d like to compare the behavior of UNLOGGED, TEMP, and FOREIGN tables with
PostgreSQL streaming (physical) replication. PostgreSQL sets a clear
expectation there: these relations are not made available on the replica.
I think we could follow a simi
these table types cannot be replicated, it doesn’t make sense to
> keep them as part of a publication — that breaks user expectations.
>
> What are your thoughts?
>
> Thanks,
> Arun
>
> On Mon, 15 Dec 2025 at 14:11, Arunprasad Rajkumar
> wrote:
>
>> Hello Amit,
&
sense to keep
them as part of a publication — that breaks user expectations.
What are your thoughts?
Thanks,
Arun
On Mon, 15 Dec 2025 at 14:11, Arunprasad Rajkumar
wrote:
> Hello Amit,
>
> Thank you for reviewing the patch and sharing your valuable feedback.
>
> I did not try wit
Postgres partition with foreign table as child partition:
- Added into the publication when PUBLISH_VIA_PARTITION_ROOT=true,
- Could create subscription, but initial data sync fails.
- Probably this could be fixed to work very similar to an UNLOGGED table?
If so, should we allow adding foreign ta
Hi,
I would like to propose a patch that improves the handling of table
inheritance
hierarchies when adding tables to publications for logical replication.
Problem:
Currently, when attempting to add a parent table to a publication using,
the operation fails
with an error if any of the inherited c
