Re: pg_upgrade and logical replication - Mailing list pgsql-hackers

From vignesh C
Subject Re: pg_upgrade and logical replication
Date
Msg-id CALDaNm0z=fLtio1h50K8WossUGXU+gy0H9y9=RYh1DDZiq2EDw@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade and logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: pg_upgrade and logical replication
Re: pg_upgrade and logical replication
List pgsql-hackers
On Mon, 19 Feb 2024 at 12:38, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Feb 19, 2024 at 6:54 AM Hayato Kuroda (Fujitsu)
> <kuroda.hayato@fujitsu.com> wrote:
> >
> > Thanks for reviewing! PSA new version.
> >
>
> Pushed this after making minor changes in the comments.

Recently there was a failure in 004_subscription tap test at [1].
In this failure, the tab_upgraded1 table was expected to have 51
records but has only 50 records. Before the upgrade both publisher and
subscriber have 50 records.
After the upgrade we have inserted one record in the publisher, now
tab_upgraded1 will have 51 records in the publisher. Then we start the
subscriber after changing max_logical_replication_workers so that
apply workers get started and apply the changes received. After
starting we enable regress_sub5, wait for sync of regress_sub5
subscription and check for tab_upgraded1 and tab_upgraded2 table data.
In a few random cases the one record that was inserted into
tab_upgraded1 table will not get replicated as we have not waited for
regress_sub4 subscription to apply the changes from the publisher.
The attached patch has changes to wait for regress_sub4 subscription
to apply the changes from the publisher before verifying the data.

[1] - https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba&dt=2024-03-26%2004%3A23%3A13

Regards,
Vignesh

Attachment

pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Statistics Import and Export
Next
From: John Naylor
Date:
Subject: Re: Change GUC hashtable to use simplehash?