| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Refactor pg_rewind code and make it work against a standby |
| Date: | 2020-11-20 21:09:34 |
| Message-ID: | 51ca9af5-1835-b1cb-5633-c3409289fe0e@iki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 20/11/2020 19:14, Andres Freund wrote:
> Hi,
>
> On 2020-11-20 16:19:03 +0200, Heikki Linnakangas wrote:
>> Pushed a fix similar to your patch, but I put the wait_for_catchup() before
>> running pg_rewind. The point of inserting the 'in A, after C was promoted'
>> row is that it's present in B when pg_rewind runs.
>
> Hm - don't we possibly need *both*? Since post pg_rewind recovery starts
> at the previous checkpoint, it's quite possible for C to get ready to
> answer queries before that record has been replayed?
No, C will not reach consistent state until all the WAL in the source
system has been replayed. pg_rewind will set minRecoveryPoint to the
minRecoveryPoint of the source system, after copying all the files. (Or
its insert point, if it's not a standby server, but in this case it is).
Same as when taking an online backup.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2020-11-20 21:13:05 | Default role -> Predefined role |
| Previous Message | Tom Lane | 2020-11-20 20:57:46 | Re: Strange behavior with polygon and NaN |