Re: skip replication slot snapshot/map file removal during end-of-recovery checkpoint
От | Bossart, Nathan |
---|---|
Тема | Re: skip replication slot snapshot/map file removal during end-of-recovery checkpoint |
Дата | |
Msg-id | 091881BB-96B3-46EF-95B6-0C0B70A09829@amazon.com обсуждение исходный текст |
Ответ на | Re: skip replication slot snapshot/map file removal during end-of-recovery checkpoint (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: skip replication slot snapshot/map file removal during end-of-recovery checkpoint
|
Список | pgsql-hackers |
On 12/23/21, 3:17 AM, "Bharath Rupireddy" <bharath.rupireddyforpostgres@gmail.com> wrote: > Currently the end-of-recovery checkpoint can be much slower, impacting > the server availability, if there are many replication slot files > XXXX.snap or map-XXXX to be enumerated and deleted. How about skipping > the .snap and map- file handling during the end-of-recovery > checkpoint? It makes the server available faster and the next regular > checkpoint can deal with these files. If required, we can have a GUC > (skip_replication_slot_file_handling or some other better name) to > control this default being the existing behavior. I suggested something similar as a possibility in the other thread where these tasks are being discussed [0]. I think it is worth considering, but IMO it is not a complete solution to the problem. If there are frequently many such files to delete and regular checkpoints are taking longer, the shutdown/end-of-recovery checkpoint could still take a while. I think it would be better to separate these tasks from checkpointing instead. Nathan [0] https://postgr.es/m/A285A823-0AF2-4376-838E-847FA4710F9A%40amazon.com
В списке pgsql-hackers по дате отправления: