On 2019-Apr-29, Tom Lane wrote:
> Ashwin Agrawal <aagrawal@pivotal.io> writes:
> > On Mon, Apr 29, 2019 at 10:36 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Can you try applying a1a789eb5ac894b4ca4b7742f2dc2d9602116e46
> >> to see if it fixes the problem for you?
>
> > Yes, will give it a try on greenplum and report back the result.
>
> > Have we decided if this will be applied to back branches?
Hi Ashwin, did you have the chance to try this out?
> My feeling about it is "maybe eventually, but most definitely not
> the week before a set of minor releases". Some positive experience
> with Greenplum would help increase confidence in the patch, for sure.
I looked at the buildfarm failures for the recoveryCheck stage. It
looks like there is only one failure for branch master after this
commit, which was chipmunk saying:
# poll_query_until timed out executing this query:
# SELECT application_name, sync_priority, sync_state FROM pg_stat_replication ORDER BY application_name;
# expecting this output:
# standby1|1|sync
# standby2|2|sync
# standby3|2|potential
# standby4|2|potential
# last actual query output:
# standby1|1|sync
# standby2|2|potential
# standby3|2|sync
# standby4|2|potential
# with stderr:
not ok 6 - asterisk comes before another standby name
# Failed test 'asterisk comes before another standby name'
# at t/007_sync_rep.pl line 26.
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunk&dt=2019-05-12%2020%3A37%3A11
AFAICS this is wholly unrelated to the problem at hand.
No other animal failed recoveryCheck test; before the commit, the
failure was not terribly frequent, but rarely would 10 days go by
without it failing. So I suggest that the bug has indeed been fixed.
Maybe now's a good time to get it back-patched? In branch
REL_11_STABLE, it failed as recently as 11 days ago in gull,
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gull&dt=2019-06-01%2004%3A11%3A36
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services