public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Control temporary files removal after crash
4+ messages / 4 participants
[nested] [flat]
* [PATCH] Control temporary files removal after crash
@ 2020-05-25 03:08 Euler Taveira <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Euler Taveira @ 2020-05-25 03:08 UTC (permalink / raw)
A new GUC remove_temp_files_after_crash controls whether temporary
files are removed after a crash. Successive crashes could result in
useless storage usage until service is restarted. It could be the case
on host with inadequate resources. This manual intervention for some
environments is not desirable. This GUC is marked as SIGHUP hence you
don't have to interrupt the service to change it.
The current behavior introduces a backward incompatibility (minor one)
which means Postgres will reclaim temporary file space after a crash.
The main reason is that we favor service continuity over debugging.
---
doc/src/sgml/config.sgml | 18 ++
src/backend/postmaster/postmaster.c | 5 +
src/backend/storage/file/fd.c | 12 +-
src/backend/utils/misc/guc.c | 9 +
src/backend/utils/misc/postgresql.conf.sample | 2 +
src/include/postmaster/postmaster.h | 1 +
src/test/recovery/t/022_crash_temp_files.pl | 194 ++++++++++++++++++
7 files changed, 236 insertions(+), 5 deletions(-)
create mode 100644 src/test/recovery/t/022_crash_temp_files.pl
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 967de73596..1b102960d6 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -9665,6 +9665,24 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
</listitem>
</varlistentry>
+ <varlistentry id="guc-remove-temp-files-after-crash" xreflabel="remove_temp_files_after_crash">
+ <term><varname>remove_temp_files_after_crash</varname> (<type>boolean</type>)
+ <indexterm>
+ <primary><varname>remove_temp_files_after_crash</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ When set to on, <productname>PostgreSQL</productname> will automatically
+ remove temporary files after a backend crash. When disabled, the temporary
+ files are retained after a crash, which may be useful in some circumstances
+ (e.g. during debugging). It may however result in accumulation of many
+ useless files, or possibly even running out of disk space.
+ It defaults to <literal>on</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-data-sync-retry" xreflabel="data_sync_retry">
<term><varname>data_sync_retry</varname> (<type>boolean</type>)
<indexterm>
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index edab95a19e..2338892c33 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -242,6 +242,7 @@ bool Db_user_namespace = false;
bool enable_bonjour = false;
char *bonjour_name;
bool restart_after_crash = true;
+bool remove_temp_files_after_crash = true;
/* PIDs of special child processes; 0 when not running */
static pid_t StartupPID = 0,
@@ -3975,6 +3976,10 @@ PostmasterStateMachine(void)
ereport(LOG,
(errmsg("all server processes terminated; reinitializing")));
+ /* remove leftover temporary files after a crash */
+ if (remove_temp_files_after_crash)
+ RemovePgTempFiles();
+
/* allow background workers to immediately restart */
ResetBackgroundWorkerCrashTimes();
diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c
index b58502837a..dfc3c2fe3e 100644
--- a/src/backend/storage/file/fd.c
+++ b/src/backend/storage/file/fd.c
@@ -3024,11 +3024,13 @@ CleanupTempFiles(bool isCommit, bool isProcExit)
* remove any leftover files created by OpenTemporaryFile and any leftover
* temporary relation files created by mdcreate.
*
- * NOTE: we could, but don't, call this during a post-backend-crash restart
- * cycle. The argument for not doing it is that someone might want to examine
- * the temp files for debugging purposes. This does however mean that
- * OpenTemporaryFile had better allow for collision with an existing temp
- * file name.
+ * During post-backend-crash restart cycle, this routine could be called if
+ * remove_temp_files_after_crash GUC is enabled. Multiple crashes while
+ * queries are using temp files could result in useless storage usage that can
+ * only be reclaimed by a service restart. The argument against enabling it is
+ * that someone might want to examine the temp files for debugging purposes.
+ * This does however mean that OpenTemporaryFile had better allow for
+ * collision with an existing temp file name.
*
* NOTE: this function and its subroutines generally report syscall failures
* with ereport(LOG) and keep going. Removing temp files is not so critical
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 3fd1a5fbe2..64ac48b2e5 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -1361,6 +1361,15 @@ static struct config_bool ConfigureNamesBool[] =
true,
NULL, NULL, NULL
},
+ {
+ {"remove_temp_files_after_crash", PGC_SIGHUP, ERROR_HANDLING_OPTIONS,
+ gettext_noop("Remove temporary files after backend crash."),
+ NULL
+ },
+ &remove_temp_files_after_crash,
+ true,
+ NULL, NULL, NULL
+ },
{
{"log_duration", PGC_SUSET, LOGGING_WHAT,
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index ee06528bb0..25c1b89ffc 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -759,6 +759,8 @@
#exit_on_error = off # terminate session on any error?
#restart_after_crash = on # reinitialize after backend crash?
+#remove_temp_files_after_crash = on # remove temporary files after
+# # backend crash?
#data_sync_retry = off # retry or panic on failure to fsync
# data?
# (change requires restart)
diff --git a/src/include/postmaster/postmaster.h b/src/include/postmaster/postmaster.h
index cfa59c4dc0..0efdd7c232 100644
--- a/src/include/postmaster/postmaster.h
+++ b/src/include/postmaster/postmaster.h
@@ -29,6 +29,7 @@ extern bool log_hostname;
extern bool enable_bonjour;
extern char *bonjour_name;
extern bool restart_after_crash;
+extern bool remove_temp_files_after_crash;
#ifdef WIN32
extern HANDLE PostmasterHandle;
diff --git a/src/test/recovery/t/022_crash_temp_files.pl b/src/test/recovery/t/022_crash_temp_files.pl
new file mode 100644
index 0000000000..45a70a368e
--- /dev/null
+++ b/src/test/recovery/t/022_crash_temp_files.pl
@@ -0,0 +1,194 @@
+#
+# Test cleanup of temporary files after a crash.
+#
+# This is a description that I will add later.
+#
+use strict;
+use warnings;
+use PostgresNode;
+use TestLib;
+use Test::More;
+use Config;
+use Time::HiRes qw(usleep);
+
+plan tests => 9;
+
+
+# To avoid hanging while expecting some specific input from a psql
+# instance being driven by us, add a timeout high enough that it
+# should never trigger even on very slow machines, unless something
+# is really wrong.
+my $psql_timeout = IPC::Run::timer(60);
+
+my $node = get_new_node('node_crash');
+$node->init();
+$node->start();
+
+# By default, PostgresNode doesn't restart after crash
+# Reduce work_mem to generate temporary file with a few number of rows
+$node->safe_psql(
+ 'postgres',
+ q[ALTER SYSTEM SET remove_temp_files_after_crash = on;
+ ALTER SYSTEM SET log_connections = 1;
+ ALTER SYSTEM SET work_mem = '64kB';
+ ALTER SYSTEM SET restart_after_crash = on;
+ SELECT pg_reload_conf();]);
+
+# create table, insert rows
+$node->safe_psql(
+ 'postgres',
+ q[CREATE TABLE tab_crash (a text);
+ INSERT INTO tab_crash (a) SELECT gen_random_uuid() FROM generate_series(1, 500);]);
+
+#
+# Test cleanup temporary files after crash
+#
+
+# Run psql, keeping session alive, so we have an alive backend to kill.
+my ($killme_stdin, $killme_stdout, $killme_stderr) = ('', '', '');
+my $killme = IPC::Run::start(
+ [
+ 'psql', '-X', '-qAt', '-v', 'ON_ERROR_STOP=1', '-f', '-', '-d',
+ $node->connstr('postgres')
+ ],
+ '<',
+ \$killme_stdin,
+ '>',
+ \$killme_stdout,
+ '2>',
+ \$killme_stderr,
+ $psql_timeout);
+
+# Get backend pid
+$killme_stdin .= q[
+SELECT pg_backend_pid();
+];
+ok(pump_until($killme, \$killme_stdout, qr/[[:digit:]]+[\r\n]$/m),
+ 'acquired pid for SIGKILL');
+my $pid = $killme_stdout;
+chomp($pid);
+$killme_stdout = '';
+$killme_stderr = '';
+
+# Run the query that generates a temporary file and that will be killed before
+# it finishes. Since the query that generates the temporary file does not
+# return before the connection is killed, use a SELECT before to trigger
+# pump_until.
+$killme_stdin .= q[
+BEGIN;
+SELECT $$in-progress-before-sigkill$$;
+WITH foo AS (SELECT a FROM tab_crash ORDER BY a) SELECT a, pg_sleep(1) FROM foo;
+];
+ok(pump_until($killme, \$killme_stdout, qr/in-progress-before-sigkill/m),
+ 'select in-progress-before-sigkill');
+$killme_stdout = '';
+$killme_stderr = '';
+
+# Kill with SIGKILL
+my $ret = TestLib::system_log('pg_ctl', 'kill', 'KILL', $pid);
+is($ret, 0, 'killed process with KILL');
+
+# Close psql session
+$killme->finish;
+
+# Wait till server restarts
+$node->poll_query_until('postgres', 'SELECT 1', '1');
+
+# Check for temporary files
+is($node->safe_psql(
+ 'postgres',
+ 'SELECT COUNT(1) FROM pg_ls_dir($$base/pgsql_tmp$$)'),
+ qq(0), 'no temporary files');
+
+#
+# Test old behavior (doesn't cleanup temporary file after crash)
+#
+$node->safe_psql(
+ 'postgres',
+ q[ALTER SYSTEM SET remove_temp_files_after_crash = off;
+ SELECT pg_reload_conf();]);
+
+# Restart psql session
+($killme_stdin, $killme_stdout, $killme_stderr) = ('', '', '');
+$killme->run();
+
+# Get backend pid
+$killme_stdin .= q[
+SELECT pg_backend_pid();
+];
+ok(pump_until($killme, \$killme_stdout, qr/[[:digit:]]+[\r\n]$/m),
+ 'acquired pid for SIGKILL');
+$pid = $killme_stdout;
+chomp($pid);
+$killme_stdout = '';
+$killme_stderr = '';
+
+# Run the query that generates a temporary file and that will be killed before
+# it finishes. Since the query that generates the temporary file does not
+# return before the connection is killed, use a SELECT before to trigger
+# pump_until.
+$killme_stdin .= q[
+BEGIN;
+SELECT $$in-progress-before-sigkill$$;
+WITH foo AS (SELECT a FROM tab_crash ORDER BY a) SELECT a, $$in-progress-before-sigkill$$, pg_sleep(1) FROM foo;
+];
+ok(pump_until($killme, \$killme_stdout, qr/in-progress-before-sigkill/m),
+ 'select in-progress-before-sigkill');
+$killme_stdout = '';
+$killme_stderr = '';
+
+# Kill with SIGKILL
+$ret = TestLib::system_log('pg_ctl', 'kill', 'KILL', $pid);
+is($ret, 0, 'killed process with KILL');
+
+# Close psql session
+$killme->finish;
+
+# Wait till server restarts
+$node->poll_query_until('postgres', 'SELECT 1', '1');
+
+# Check for temporary files -- should be there
+is($node->safe_psql(
+ 'postgres',
+ 'SELECT COUNT(1) FROM pg_ls_dir($$base/pgsql_tmp$$)'),
+ qq(1), 'one temporary file');
+
+# Restart should remove the temporary files
+$node->restart();
+
+# Check the temporary files -- should be gone
+is($node->safe_psql(
+ 'postgres',
+ 'SELECT COUNT(1) FROM pg_ls_dir($$base/pgsql_tmp$$)'),
+ qq(0), 'temporary file was removed');
+
+$node->stop();
+
+# Pump until string is matched, or timeout occurs
+sub pump_until
+{
+ my ($proc, $stream, $untl) = @_;
+ $proc->pump_nb();
+ while (1)
+ {
+ last if $$stream =~ /$untl/;
+ if ($psql_timeout->is_expired)
+ {
+ diag("aborting wait: program timed out");
+ diag("stream contents: >>", $$stream, "<<");
+ diag("pattern searched for: ", $untl);
+
+ return 0;
+ }
+ if (not $proc->pumpable())
+ {
+ diag("aborting wait: program died");
+ diag("stream contents: >>", $$stream, "<<");
+ diag("pattern searched for: ", $untl);
+
+ return 0;
+ }
+ $proc->pump();
+ }
+ return 1;
+}
--
2.29.2
--------------002C097FE66DA941AEB9F7C8--
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Can we remove support for standard_conforming_strings = off yet?
@ 2026-01-05 12:01 Julien Rouhaud <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Julien Rouhaud @ 2026-01-05 12:01 UTC (permalink / raw)
To: John Naylor <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]
On Mon, Jan 05, 2026 at 05:03:48PM +0700, John Naylor wrote:
> On Thu, Jan 1, 2026 at 12:04 AM Tom Lane <[email protected]> wrote:
> > Personally I would call it a deal-breaker if I thought it'd affect
> > more than a very very tiny number of people. But the entire premise
> > of this patch is that nobody is using standard_conforming_strings =
> > off in production anymore. If that isn't true it's probably a
> > mistake to go forward anyway.
>
> FWIW, I spent a few minutes looking, and I only found issues from ~5
> years ago about software not working with the setting off. I didn't
> see any details on what they were running in the application stack
> that required it:
>
> https://github.com/PostgREST/postgrest/issues/1992
>
> https://github.com/npgsql/npgsql/issues/3333
I had another one ~4 years ago:
https://github.com/powa-team/powa-archivist/issues/51
Since I fixed powa-archivist at that time, I don't know if anyone else would
have faced the same problem, although the OP is likely still using the same
setting.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Can we remove support for standard_conforming_strings = off yet?
@ 2026-01-20 18:31 Tom Lane <[email protected]>
parent: Julien Rouhaud <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2026-01-20 18:31 UTC (permalink / raw)
To: Julien Rouhaud <[email protected]>; +Cc: John Naylor <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]
Julien Rouhaud <[email protected]> writes:
> On Mon, Jan 05, 2026 at 05:03:48PM +0700, John Naylor wrote:
>> On Thu, Jan 1, 2026 at 12:04 AM Tom Lane <[email protected]> wrote:
>>> Personally I would call it a deal-breaker if I thought it'd affect
>>> more than a very very tiny number of people. But the entire premise
>>> of this patch is that nobody is using standard_conforming_strings =
>>> off in production anymore. If that isn't true it's probably a
>>> mistake to go forward anyway.
>> FWIW, I spent a few minutes looking, and I only found issues from ~5
>> years ago about software not working with the setting off. I didn't
>> see any details on what they were running in the application stack
>> that required it:
>> https://github.com/PostgREST/postgrest/issues/1992
>> https://github.com/npgsql/npgsql/issues/3333
> I had another one ~4 years ago:
> https://github.com/powa-team/powa-archivist/issues/51
> Since I fixed powa-archivist at that time, I don't know if anyone else would
> have faced the same problem, although the OP is likely still using the same
> setting.
So, nobody's actually spoken against this change. I think we should
go forward with it, for the reasons I gave at the top of the thread
and because "if not now, when?". I have little doubt that if there
is anyone still running with standard_conforming_strings = off, they
aren't going to change until forced to. So unless we want to live
with the potential security hazard forever, we're going to have to
make a breaking change sometime.
regards, tom lane
^ permalink raw reply [nested|flat] 4+ messages in thread
* Can we remove support for standard_conforming_strings = off yet?
@ 2026-01-20 20:02 David G. Johnston <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: David G. Johnston @ 2026-01-20 20:02 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Julien Rouhaud <[email protected]>; John Naylor <[email protected]>; Andrew Dunstan <[email protected]>; [email protected] <[email protected]>
On Tuesday, January 20, 2026, Tom Lane <[email protected]> wrote:
> I think we should go forward with it,
>
Seems entirely reasonable for us to do this.
+1
David J.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-01-20 20:02 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-05-25 03:08 [PATCH] Control temporary files removal after crash Euler Taveira <[email protected]>
2026-01-05 12:01 Re: Can we remove support for standard_conforming_strings = off yet? Julien Rouhaud <[email protected]>
2026-01-20 18:31 ` Re: Can we remove support for standard_conforming_strings = off yet? Tom Lane <[email protected]>
2026-01-20 20:02 ` Can we remove support for standard_conforming_strings = off yet? David G. Johnston <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox