Re: Failure of subscription tests with topminnow
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Ajin Cherian <itsajin@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
Michael Paquier <michael@paquier.xyz>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-08-25T13:13:49Z
Lists: pgsql-hackers
On Wed, Aug 25, 2021 at 5:54 PM Ajin Cherian <itsajin@gmail.com> wrote:
>
> On Wed, Aug 25, 2021 at 9:32 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> >
> > IIUC the query[1] used for polling returns two rows in this case: {t,
> > f} or {f, t}. But did poll_query_until() returned OK in this case even
> > if we expected one row of 't'? My guess of how this issue happened is:
> >
> > 1. the first polling query after "ATLER SUBSCRIPTION CONNECTION"
> > passed (for some reason).
> > 2. all wal senders exited.
> > 3. get the pid of wal sender with application_name 'tap_sub' but got nothing.
> > 4. the second polling query resulted in a syntax error since $oldpid is null.
> >
> > If the fact that two walsender with the same application_name could
> > present in pg_stat_replication view was the cause of this issue,
> > poll_query_until() should return OK even if we expected just 't'. I
> > might be missing something, though.
> >
> > [1] "SELECT pid != $oldpid FROM pg_stat_replication WHERE
> > application_name = '$appname';"
>
> Yes, the query [1] returns OK with a {f,t} or {t,f}
>
> [1] - "SELECT pid != $oldpid FROM pg_stat_replication WHERE
> application_name = '$appname';"
>
Can you additionally check the value of 'state' from
pg_stat_replication for both the old and new walsender sessions?
--
With Regards,
Amit Kapila.
Commits
-
Fix the random test failure in 001_rep_changes.
- 8d0138ef51b5 15.0 landed
- b7ad093d50e1 14.0 landed
- 387093e43225 10.19 landed
- 56683e1684ef 11.14 landed
- df6ab94aca90 12.9 landed
- b51985d8a0e1 13.5 landed