Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix CREATE SUBSCRIPTION failure when the publisher runs on pre-PG19.

  2. Fix version check for retain_dead_tuples subscription option.

  1. Two issues with version checks in CREATE SUBSCRIPTION

    Fujii Masao <masao.fujii@gmail.com> — 2025-12-22T17:26:42Z

    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
    
  2. Re: Two issues with version checks in CREATE SUBSCRIPTION

    Amit Kapila <amit.kapila16@gmail.com> — 2025-12-23T04:51:16Z

    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.
    
    
    
    
  3. RE: Two issues with version checks in CREATE SUBSCRIPTION

    Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> — 2025-12-23T05:55:41Z

    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
    
    
  4. Re: Two issues with version checks in CREATE SUBSCRIPTION

    Fujii Masao <masao.fujii@gmail.com> — 2025-12-23T08:51:27Z

    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
    
    
    
    
  5. Re: Two issues with version checks in CREATE SUBSCRIPTION

    Shlok Kyal <shlok.kyal.oss@gmail.com> — 2025-12-23T10:18:05Z

    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
    
    
    
    
  6. Re: Two issues with version checks in CREATE SUBSCRIPTION

    Fujii Masao <masao.fujii@gmail.com> — 2025-12-24T14:48:25Z

    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