From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Euler Taveira <euler(at)eulerto(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: O(n) tasks cause lengthy startups and checkpoints |
Date: | 2021-12-02 21:19:16 |
Message-ID: | 18ED8B1F-7F5B-4ABF-848D-45916C938BC7@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/1/21, 6:06 PM, "Euler Taveira" <euler(at)eulerto(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-12-02 21:22:21 | Dubious usage of TYPCATEGORY_STRING |
Previous Message | Andrew Dunstan | 2021-12-02 20:46:09 | Re: pg_dump versus ancient server versions |