Re: O(n) tasks cause lengthy startups and checkpoints
От | Bossart, Nathan |
---|---|
Тема | Re: O(n) tasks cause lengthy startups and checkpoints |
Дата | |
Msg-id | 18ED8B1F-7F5B-4ABF-848D-45916C938BC7@amazon.com обсуждение исходный текст |
Ответ на | Re: O(n) tasks cause lengthy startups and checkpoints ("Euler Taveira" <euler@eulerto.com>) |
Список | pgsql-hackers |
On 12/1/21, 6:06 PM, "Euler Taveira" <euler@eulerto.com> wrote: > Saying that a certain task is O(n) doesn't mean it needs a separate process to > handle it. Did you have a use case or even better numbers (% of checkpoint / > startup time) that makes your proposal worthwhile? I don't have specific numbers on hand, but each of the four functions I listed is something I routinely see impacting customers. > For (3), there is already a GUC that would avoid the slowdown during startup. > Use it if you think the startup time is more important that disk space occupied > by useless files. Setting remove_temp_files_after_crash to false only prevents temp file cleanup during restart after a backend crash. It is always called for other startups. > For (4), you are forgetting that the on-disk state of replication slots is > stored in the pg_replslot/SLOTNAME/state. It seems you cannot just rename the > replication slot directory and copy the state file. What happen if there is a > crash before copying the state file? Good point. I think it's possible to deal with this, though. Perhaps the files that should be deleted on startup should go in a separate directory, or maybe we could devise a way to ensure the state file is copied even if there is a crash at an inconvenient time. Nathan
В списке pgsql-hackers по дате отправления: