Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint?
| От | Michael Paquier |
|---|---|
| Тема | Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint? |
| Дата | |
| Msg-id | Ye+Hk413NtJ/yPoi@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint? (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
| Ответы |
Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint?
|
| Список | pgsql-hackers |
On Mon, Jan 10, 2022 at 11:04:05AM +0530, Bharath Rupireddy wrote: > On Mon, Jan 10, 2022 at 10:58 AM Jaime Casanova > <jcasanov@systemguards.com.ec> wrote: >> Now; I do think that the secondd patch, the one that just skips update >> of the state in control file, is the way to go. The other patch adds too >> much complexity for a small return. > > Thanks. Attaching the above patch. I agree that the addition of DB_IN_END_OF_RECOVERY_CHECKPOINT is not necessary as the control file state will be reflected in a live server once it the instance is ready to write WAL after promotion, as much as I agree that the state stored in the control file because of the end-of-recovery record does not reflect the reality. Now, I also find confusing the state of CreateCheckpoint() once this patch gets applied. Now the code and comments imply that an end-of-recovery checkpoint is a shutdown checkpoint because they perform the same actions, which is fine. Could it be less confusing to remove completely the "shutdown" variable instead and replace those checks with "flags"? What the patch is doing is one step in this direction. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: