Re: Loss of replication after simple misconfiguration

From: Victor Yegorov <vyegorov(at)gmail(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: hubert depesz lubaczewski <depesz(at)depesz(dot)com>, pgsql-bugs mailing list <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Loss of replication after simple misconfiguration
Date: 2020-04-09 16:48:17
Message-ID: CAGnEboj9igBHb8hF2Ls4oNOJJ2EN3xBRm__SXg1i_N+T+v=WEQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

чт, 9 апр. 2020 г. в 19:19, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>:

> So I've been assisting hubert with analysis of this on IRC, and what we
> have found so far suggests:
>
> 1. the max_worker_processes thing is a red herring
>
> 2. It is virtually certain that the restart, in addition to changing
> max_worker_processes on the master, also changed the master's setting of
> track_commit_timestamp from off to on (which is clearly relevant to the
> issue)
>
> …
>
> I did notice that 9.5.15 does have a fix for an issue in this area, but
> I didn't see any more recent changes - did I miss anything?
>

We've hit similar issue last week, but on 11.5 — we
had track_commit_timestamp enabled on master after switchover,
replica failed to start.

It might be, that fix was here:
https://git.postgresql.org/pg/commitdiff/180feb8c7e
(For 9.5 branch it is: https://git.postgresql.org/pg/commitdiff/69a5686368)

We're not in the position to test it again, though…

--
Victor Yegorov

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Johannes Mols 2020-04-09 17:42:04 Re: BUG #16351: PostgreSQL closing connection during requests with segmentation fault
Previous Message Jehan-Guillaume de Rorthais 2020-04-09 16:46:22 Re: [BUG] non archived WAL removed during production crash recovery