> On Jun 2, 2026, at 14:14, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Jun 1, 2026 at 6:42 PM Chao Li <li.evan.chao@gmail.com> wrote:
>>
>> While testing “Support existing publications in pg_createsubscriber”, I noticed that it doesn’t allow the same
publicationname even when the publications are from different databases.
>>
>> A simple repro:
>> ```
>> % createdb db1
>> % createdb db2
>> % psql db1 -c 'CREATE PUBLICATION app_pub FOR ALL TABLES'
>> % psql db2 -c 'CREATE PUBLICATION app_pub FOR ALL TABLES'
>> CREATE PUBLICATION
>> CREATE PUBLICATION
>> % pg_createsubscriber --dry-run --pgdata <data-dir> --publisher-server postgres --database db1 --database db2
--publicationapp_pub --publication app_pub
>> pg_createsubscriber: error: publication "app_pub" specified more than once for --publication
>> ```
>>
>> The rejection is not introduced by this feature, but previously it was not a real problem because the specified
publicationnames would always be created. After this feature, it may become an issue, since the feature intends to use
existingpublications, and users may have defined publications with the same name in different databases. So the current
restrictionbecomes a limitation of the new feature. I don’t think we should leave this limitation in PG19.
>>
>> Since pg_createsubscriber already ensures that duplicate database names cannot be specified, we can just remove the
duplicatepublication name check.
>>
>
> Doesn't the same point apply to subscription names? The subscription
> names can be specified by "--subscription=name"
>
> --
> With Regards,
> Amit Kapila.
In theory, yes, since subscription names are also unique per database. I didn’t include that in v1 because the
publication-nameissue affects the new PG19 feature for reusing existing publications, whereas allowing duplicate
subscriptionnames seems like an improvement that could be a material of v20.
As you ask, I put the subscription-name change in 0002. Please decide how to proceed. If you decide to accept both,
theycan be squashed.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
