Re: Failure of subscription tests with topminnow - Mailing list pgsql-hackers

From Ajin Cherian
Subject Re: Failure of subscription tests with topminnow
Date
Msg-id CAFPTHDaWRt99tg=A1urx1tkhQ0GECKc67QV1cWJRH9x9fK2JzQ@mail.gmail.com
Whole thread Raw
In response to Re: Failure of subscription tests with topminnow  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Failure of subscription tests with topminnow  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
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';"

regards,
Ajin Cherian
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Failure of subscription tests with topminnow
Next
From: "alvherre@alvh.no-ip.org"
Date:
Subject: Re: prevent immature WAL streaming