Re: Loss of replication after simple misconfiguration

From: hubert depesz lubaczewski <depesz(at)depesz(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Victor Yegorov <vyegorov(at)gmail(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-bugs mailing list <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Loss of replication after simple misconfiguration
Date: 2020-04-10 08:01:22
Message-ID: 20200410080122.GA23421@depesz.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Apr 10, 2020 at 04:59:32PM +0900, Michael Paquier wrote:
> On Fri, Apr 10, 2020 at 09:26:51AM +0200, hubert depesz lubaczewski wrote:
> > In our case it was *at least* this scenario:
> >
> > 1. master and slave both with max_worker_processes and
> > track_commit_timestamp off.
> > 2. config files get changed on both to include track_commit_timestamp on
> > 3. slave gets restarted
> > 4. config files get changed on both to include max_worker_processes = 50
> > 5. master gets stopped by "power outage"
> > 6. after master re-starts, replication to slave dies.
>
> Without the standby restarted here, its configuration remains at the
> former value of max_worker_processes, which is lower than the setting
> of the primary, so it would logically stop in this case if not
> restarted once it replays the XLOG_PARAMETER_CHANGE record generated
> from the primary.

Yes, I know. And this is *precisely* what has happened in at least one
case.
But I would assume that after restart, standby should be working. Which
didn't happen (in at least one case, we had lots of restarts recently,
and only ~ 4 cases of replication dying).

Best regards,

depesz

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message ribal 2020-04-10 08:21:32 pg_tables anomalies
Previous Message Michael Paquier 2020-04-10 07:59:32 Re: Loss of replication after simple misconfiguration