Re: Refactor pg_rewind code and make it work against a standby
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Refactor pg_rewind code and make it work against a standby |
| Дата | |
| Msg-id | 51ca9af5-1835-b1cb-5633-c3409289fe0e@iki.fi обсуждение исходный текст |
| Ответ на | Re: Refactor pg_rewind code and make it work against a standby (Andres Freund <andres@anarazel.de>) |
| Список | 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
В списке pgsql-hackers по дате отправления: