Re: [Bug Fix]standby may crash when switching-over in certain special cases

From: px shi <spxlyy123(at)gmail(dot)com>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Bug Fix]standby may crash when switching-over in certain special cases
Date: 2024-08-21 01:11:03
Message-ID: CAAccyY+dx+yE6WNiyVBx8BiVj5jWACKeNNfCSBo0veV15yOnZQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> 于2024年8月21日周三 00:49写道:

>
>
> > Is s1 a cascading standby of s2? If otherwise s1 and s2 is the standbys
> of
> > the primary server respectively, it is not surprising that s2 has
> progressed
> > far than s1 when the primary fails. I believe that this is the case you
> should
> > use pg_rewind. Even if flushedUpto is reset as proposed in your patch,
> s2 might
> > already have applied a WAL record that s1 has not processed yet, and
> there
> > would be no gurantee that subsecuent applys suceed.
>
>
Thank you for your response. In my scenario, s1 and s2 is the standbys of
the primary server respectively, and s1 a synchronous standby and s2 is an
asynchronous standby. You mentioned that if s2's replay progress is ahead
of s1, pg_rewind should be used. However, what I'm trying to address is an
issue where s2 crashes during replay after s1 has been promoted to primary,
even though s2's progress hasn't surpassed s1.

Regards,
Pixian Shi

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2024-08-21 01:32:30 Re: Conflict detection and logging in logical replication
Previous Message Alvaro Herrera 2024-08-21 00:56:54 Re: Buf fix: update-po for PGXS does not work