Обсуждение: Two issues with version checks in CREATE SUBSCRIPTION

Поиск
Список
Период
Сортировка

Two issues with version checks in CREATE SUBSCRIPTION

От
Fujii Masao
Дата:
Hi,

While looking at subscription-related code, I noticed two issues related to
version checks.

        if (walrcv_server_version(wrconn) < 19000)
            ereport(ERROR,
                errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
                errmsg("cannot enable retain_dead_tuples if the
publisher is running a version earlier than PostgreSQL 19"));

First, in subscriptioncmds.c this check rejects enabling retain_dead_tuples
when the publisher is running an older version. However, the comparison uses
19000 as v19 value. Since server versions are encoded as 190000 for v19,
this appears to be a typo and allows the option to be enabled unexpectedly
on pre-v19 publishers. The attached 0001 patch fixes this by correcting
the version constant.

Second, CREATE SUBSCRIPTION with copy_data=true and origin='none' currently
fails when the publisher is running a version earlier than v19, although
this combination should be supported. The failure occurs because the command
issues a query calling pg_get_publication_sequences on the publisher,
which does not exist before v19. The attached 0002 patch fixes this
by skipping that query when the publisher runs an older version.

Thoughts?

Regards,

-- 
Fujii Masao
Вложения

Re: Two issues with version checks in CREATE SUBSCRIPTION

От
Amit Kapila
Дата:
On Mon, Dec 22, 2025 at 10:57 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> While looking at subscription-related code, I noticed two issues related to
> version checks.
>
>         if (walrcv_server_version(wrconn) < 19000)
>             ereport(ERROR,
>                 errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
>                 errmsg("cannot enable retain_dead_tuples if the
> publisher is running a version earlier than PostgreSQL 19"));
>
> First, in subscriptioncmds.c this check rejects enabling retain_dead_tuples
> when the publisher is running an older version. However, the comparison uses
> 19000 as v19 value. Since server versions are encoded as 190000 for v19,
> this appears to be a typo and allows the option to be enabled unexpectedly
> on pre-v19 publishers. The attached 0001 patch fixes this by correcting
> the version constant.
>
> Second, CREATE SUBSCRIPTION with copy_data=true and origin='none' currently
> fails when the publisher is running a version earlier than v19, although
> this combination should be supported. The failure occurs because the command
> issues a query calling pg_get_publication_sequences on the publisher,
> which does not exist before v19. The attached 0002 patch fixes this
> by skipping that query when the publisher runs an older version.
>

The changes look good to me though I haven't tested the patches. So,
please feel free to push after the relevant test. Thanks for catching
and fixing these issues.

--
With Regards,
Amit Kapila.

RE: Two issues with version checks in CREATE SUBSCRIPTION

От
"Hayato Kuroda (Fujitsu)"
Дата:
Dear Fujii-san,

Thanks for the patch! They basically look good to me.

> First, in subscriptioncmds.c this check rejects enabling retain_dead_tuples
> when the publisher is running an older version. However, the comparison uses
> 19000 as v19 value. Since server versions are encoded as 190000 for v19,
> this appears to be a typo and allows the option to be enabled unexpectedly
> on pre-v19 publishers. The attached 0001 patch fixes this by correcting
> the version constant.

One idea is to introduce a constant like RETAIN_DEAD_TUPLES_MIN_VERSION_NUM,
which avoids similar typo. Is it overengineering?

Best regards,
Hayato Kuroda
FUJITSU LIMITED

Re: Two issues with version checks in CREATE SUBSCRIPTION

От
Fujii Masao
Дата:
On Tue, Dec 23, 2025 at 2:55 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Fujii-san,
>
> Thanks for the patch! They basically look good to me.

Thanks to Amit and Hayato for the review! I'll commit the patches.


> > First, in subscriptioncmds.c this check rejects enabling retain_dead_tuples
> > when the publisher is running an older version. However, the comparison uses
> > 19000 as v19 value. Since server versions are encoded as 190000 for v19,
> > this appears to be a typo and allows the option to be enabled unexpectedly
> > on pre-v19 publishers. The attached 0001 patch fixes this by correcting
> > the version constant.
>
> One idea is to introduce a constant like RETAIN_DEAD_TUPLES_MIN_VERSION_NUM,
> which avoids similar typo. Is it overengineering?

I don't think this would be a sufficient guard against typos. Even with
this approach, we could still introduce a mistake like the following,
for example:

    #define RETAIN_DEAD_TUPLES_MIN_VERSION_NUM 19000

Also, there are many existing checks that compare against version constants
like 190000, so changing the code to use such a macro everywhere feels
like overkill to me.

Regards,

--
Fujii Masao

Re: Two issues with version checks in CREATE SUBSCRIPTION

От
Shlok Kyal
Дата:
Hi Fujii-san,

On Mon, 22 Dec 2025 at 22:57, Fujii Masao <masao.fujii@gmail.com> wrote:
>
> Hi,
>
> While looking at subscription-related code, I noticed two issues related to
> version checks.
>
>         if (walrcv_server_version(wrconn) < 19000)
>             ereport(ERROR,
>                 errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
>                 errmsg("cannot enable retain_dead_tuples if the
> publisher is running a version earlier than PostgreSQL 19"));
>
> First, in subscriptioncmds.c this check rejects enabling retain_dead_tuples
> when the publisher is running an older version. However, the comparison uses
> 19000 as v19 value. Since server versions are encoded as 190000 for v19,
> this appears to be a typo and allows the option to be enabled unexpectedly
> on pre-v19 publishers. The attached 0001 patch fixes this by correcting
> the version constant.
>
I tested this. I created a publisher in PG17 and tried creating
subscriber in PG19.

Without Patch, I am able to create the subscription with
retain_dead_tuples = true.
postgres=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=localhost
port=5432 dbname=postgres' PUBLICATION pub1 WITH (retain
_dead_tuples=true);
NOTICE:  created replication slot "sub1" on publisher
CREATE SUBSCRIPTION

With 0001 Patch, this issue is resolved.
postgres=# CREATE SUBSCRIPTION sub2 CONNECTION 'host=localhost
port=5432 dbname=postgres' PUBLICATION pub1 WITH
(retain_dead_tuples=true);
ERROR:  cannot enable retain_dead_tuples if the publisher is running a
version earlier than PostgreSQL 19

> Second, CREATE SUBSCRIPTION with copy_data=true and origin='none' currently
> fails when the publisher is running a version earlier than v19, although
> this combination should be supported. The failure occurs because the command
> issues a query calling pg_get_publication_sequences on the publisher,
> which does not exist before v19. The attached 0002 patch fixes this
> by skipping that query when the publisher runs an older version.
>
I am able to reproduce this scenario.
I created a publisher in PG17 and tried creating subscriber in PG19.

Without Patch we are hitting the following error.
postgres=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=localhost
port=5432 dbname=postgres' PUBLICATION pub1 WITH (origin='none');
ERROR:  could not receive list of replicated sequences from the
publisher: ERROR:  function pg_get_publication_sequences(name) does
not exist
LINE 3:      LATERAL pg_get_publication_sequences(P.pubname) GPS
                     ^
HINT:  No function matches the given name and argument types. You
might need to add explicit type casts.

And I confirm that the 0002 patch resolves this.

Thanks,
Shlok Kyal

Re: Two issues with version checks in CREATE SUBSCRIPTION

От
Fujii Masao
Дата:
On Tue, Dec 23, 2025 at 7:18 PM Shlok Kyal <shlok.kyal.oss@gmail.com> wrote:
>
> Hi Fujii-san,
>
> On Mon, 22 Dec 2025 at 22:57, Fujii Masao <masao.fujii@gmail.com> wrote:
> >
> > Hi,
> >
> > While looking at subscription-related code, I noticed two issues related to
> > version checks.
> >
> >         if (walrcv_server_version(wrconn) < 19000)
> >             ereport(ERROR,
> >                 errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> >                 errmsg("cannot enable retain_dead_tuples if the
> > publisher is running a version earlier than PostgreSQL 19"));
> >
> > First, in subscriptioncmds.c this check rejects enabling retain_dead_tuples
> > when the publisher is running an older version. However, the comparison uses
> > 19000 as v19 value. Since server versions are encoded as 190000 for v19,
> > this appears to be a typo and allows the option to be enabled unexpectedly
> > on pre-v19 publishers. The attached 0001 patch fixes this by correcting
> > the version constant.
> >
> I tested this. I created a publisher in PG17 and tried creating
> subscriber in PG19.
>
> Without Patch, I am able to create the subscription with
> retain_dead_tuples = true.
> postgres=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=localhost
> port=5432 dbname=postgres' PUBLICATION pub1 WITH (retain
> _dead_tuples=true);
> NOTICE:  created replication slot "sub1" on publisher
> CREATE SUBSCRIPTION
>
> With 0001 Patch, this issue is resolved.
> postgres=# CREATE SUBSCRIPTION sub2 CONNECTION 'host=localhost
> port=5432 dbname=postgres' PUBLICATION pub1 WITH
> (retain_dead_tuples=true);
> ERROR:  cannot enable retain_dead_tuples if the publisher is running a
> version earlier than PostgreSQL 19
>
> > Second, CREATE SUBSCRIPTION with copy_data=true and origin='none' currently
> > fails when the publisher is running a version earlier than v19, although
> > this combination should be supported. The failure occurs because the command
> > issues a query calling pg_get_publication_sequences on the publisher,
> > which does not exist before v19. The attached 0002 patch fixes this
> > by skipping that query when the publisher runs an older version.
> >
> I am able to reproduce this scenario.
> I created a publisher in PG17 and tried creating subscriber in PG19.
>
> Without Patch we are hitting the following error.
> postgres=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=localhost
> port=5432 dbname=postgres' PUBLICATION pub1 WITH (origin='none');
> ERROR:  could not receive list of replicated sequences from the
> publisher: ERROR:  function pg_get_publication_sequences(name) does
> not exist
> LINE 3:      LATERAL pg_get_publication_sequences(P.pubname) GPS
>                      ^
> HINT:  No function matches the given name and argument types. You
> might need to add explicit type casts.
>
> And I confirm that the 0002 patch resolves this.

Thanks for the review and test! I've pushed the patches.

Regards,

--
Fujii Masao

Чтобы сделать работу с сайтом удобнее, мы используем cookie и аналитический сервис «Яндекс.Метрика». Продолжая пользоваться сайтом, вы соглашаетесь с их использованием.