RE: Logical Replication of sequences

On Tuesday, October 14, 2025 11:13 AM Kuroda, Hayato/黒田 隼人 <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> Dear Vignesh,
>
> Thanks for updating the patch. Here are comments for 0002.
>
> ```
> + if (pubrelkind == '\0')
> + return;
> ```
>
> Instead of adding this part, can we provide another function which only checks
> the type mismatch? New one can be called from CreateSubscription() and
> AlterSubscription_refresh().

Per analysis, the checks in the function should be performed for all the cases,
so I did not add a new function.

>
> ```
> +#include "nodes/primnodes.h"
> ...
> +typedef struct SubscriptionRelKind
> +{
> + RangeVar *rv;
> + char relkind;
> +}
> ```
>
> The data structure is used in subscriptioncmds.c. Can we move the definition
> to the file?
> Also, `relkind` indicates the type of relation on publisher. Can you clarify the
> point like `relkind_on_pub`?

I chose to change the type name from SubscriptionRelKind to
PublicationRelKind since it is used to describe the relation on publisher.

Attach the latest patch that includes the following changes:

0001:
* Addressed Peter's comments[1]

0002:
* Addressed Amit's comments[2]
* Addressed Shveta's comments[3]
* Addressed Kuroda's comments[4]
* Fixed an issue where check_publications_origin checked
partitions and ancestors of sequences that were unnecessary.
* Fixed an issue where check_publications_origin performed redundant checks on
the origin, even when origin option is set to ANY.
* Fixed an issue where check_publications_origin unnecessarily checked sequences
when only table checks are required, particularly when retain_dead_tuples is
true and the origin is set to ANY.
* Changed CheckSubscriptionRelkind to do the relkind match check during replication
as well. This ensures detection of relkind mismatches, when a local table on
the subscriber is dropped and subsequently replaced by a new sequence with the
same name after the initial sync.

0003~0005:
Unchanged.

TODO:
* The latest comment from Shveta[5].
* The comment from Amit[6] to avoid creating slot/origin for sequence only subscription.

[1] https://www.postgresql.org/message-id/CAHut%2BPuDCMu5QDmAo%2BMW0hKSThACfqfaPBGcwrBOUFE3RUPP%3Dw%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CAA4eK1%2BSMY-dEhnFw8wXYSygk4Xr%2BSZJ-zEnuhxb%2BFmFrN0AzQ%40mail.gmail.com
[3] https://www.postgresql.org/message-id/CAJpy0uC5H0jtmUEN8ES_PAMaYCfjmqEVuJiCdB%3DAa98ivqc9FA%40mail.gmail.com
[4] https://www.postgresql.org/message-id/OSCPR01MB149667963060BB6A068B275B9F5EBA%40OSCPR01MB14966.jpnprd01.prod.outlook.com
[5] https://www.postgresql.org/message-id/CAJpy0uBpxor5EaSDFd0u2kXV5zgEkSq7g6iaSNwVXY0U1Rk4iA%40mail.gmail.com
[6] https://www.postgresql.org/message-id/CAA4eK1J%3Dgc8WXVc2Hy0Xcq4KtWU-z-dxBiZHbT62jz3QPBZ5CQ%40mail.gmail.com

Best Regards,
Hou zj