Re: Standby corruption after master is restarted - Mailing list pgsql-bugs

From Emre Hasegeli
Subject Re: Standby corruption after master is restarted
Date
Msg-id CAE2gYzwB0+MM3L6-zdK0JKO_aXqHNCKU7VAiDJk_kKRRJ4B=yA@mail.gmail.com
Whole thread Raw
In response to Re: Standby corruption after master is restarted  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Standby corruption after master is restarted  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Re: Standby corruption after master is restarted  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-bugs
> OK, this seems to confirm the theory that there's a race condition between
> segment recycling and replicating. It's likely limited to short period after
> a crash, otherwise we'd probably see many more reports.

I am suspicious about this part.  It cannot be happening 2 times to us
and never to anybody else.  Maybe people do not report it because it
is easy to deal with the problem.  You just delete the corrupted WAL
file.  Or maybe there is something special in our infrastructure.

Thank you for your help so far.

>> This is the connection information.  Although the master shows SSL
>> compression is disabled in despite of being explicitly asked for.

> Hmmm, that seems like a separate issue. When you say 'master shows SSL
> compression is disabled' where do you see that?

I thought it might be related first, so I mentioned.  Then I found out
on pg_stat_ssl view on the server that it is actually disabled.
Probably the configuration of OpenSSL is disabling it.


pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #15160: planner overestimates number of rows in join when there are more than 200 rows coming from CTE
Next
From: Heikki Linnakangas
Date:
Subject: Re: BUG #15161: libpq - Invalid SSPI context after PQreset