Re: Run end-of-recovery checkpoint in non-wait mode or skip it entirely for faster server availability?
От | Robert Haas |
---|---|
Тема | Re: Run end-of-recovery checkpoint in non-wait mode or skip it entirely for faster server availability? |
Дата | |
Msg-id | CA+TgmoZ3=08vRE7LmdZEyi2zKoGSmS9ZSCXzpSBBzazLS--TNw@mail.gmail.com обсуждение исходный текст |
Ответ на | Run end-of-recovery checkpoint in non-wait mode or skip it entirely for faster server availability? (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Run end-of-recovery checkpoint in non-wait mode or skip it entirely for faster server availability?
|
Список | pgsql-hackers |
On Fri, Mar 25, 2022 at 3:40 AM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > Since the server spins up checkpointer process [1] while the startup > process performs recovery, isn't it a good idea to make > end-of-recovery completely optional for the users or at least run it > in non-wait mode so that the server will be available faster. The next > checkpointer cycle will take care of performing the EOR checkpoint > work, if user chooses to skip the EOR or the checkpointer will run EOR > checkpoint in background, if user chooses to run it in the non-wait > mode (without CHECKPOINT_WAIT flag). Of course by choosing this > option, users must be aware of the fact that the extra amount of > recovery work that needs to be done if a crash happens from the point > EOR gets skipped or runs in non-wait mode until the next checkpoint. > But the advantage that users get is the faster server availability. I think that we should remove end-of-recovery checkpoints completely and instead use the end-of-recovery WAL record (cf. CreateEndOfRecoveryRecord). However, when I tried to do that, I ran into some problems: http://postgr.es/m/CA+TgmobrM2jvkiccCS9NgFcdjNSgAvk1qcAPx5S6F+oJT3D2mQ@mail.gmail.com The second problem described in that email has subsequently been fixed, I believe, but the first one remains. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: