From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: cleanup temporary files after crash |
Date: | 2020-10-28 18:42:52 |
Message-ID: | 20201028184252.5vpoe65kcfebbmmf@development |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Euler,
On Wed, Oct 28, 2020 at 11:16:26AM -0300, Euler Taveira wrote:
>Hi,
>
>Bug #16427 mentioned that temporary files are not removed after a crash. I
>heard similar complaints from some customers. In the bug report [1], I
>proposed a new GUC to control whether temporary files are removed after a
>crash recovery. The current behavior is only useful for debugging purposes.
>It also has an undesirable behavior: you have to restart the service to
>reclaim the space. Interrupting the service continuity isn't always an
>option and due to limited resources, you have no choice but to restart the
>service.
>
>The new GUC cleanup_temp_files_after_crash is marked as SIGHUP. Hence, you
>can enable it to debug without service interruption. The default value is
>on which means it changes the current behavior. Documentation and tests are
>included.
>
I did a quick review and the patch seems fine to me. Let's wait for a
bit and see if there are any objections - if not, I'll get it committed
in the next CF.
One thing I'm not sure about is whether we should have the GUC as
proposed, or have a negative "keep_temp_files_after_restart" defaulting
to false. But I don't have a very good justification for the alternative
other than vague personal preference.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Kukushkin | 2020-10-28 18:44:18 | Autovacuum worker doesn't immediately exit on postmaster death |
Previous Message | Bruce Momjian | 2020-10-28 18:29:16 | Re: Internal key management system |