public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bharath Rupireddy <[email protected]>
To: Ashutosh Bapat <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Progress report removal of temp files and temp relation files using ereport_startup_progress
Date: Thu, 5 May 2022 12:11:27 +0530
Message-ID: <CALj2ACW-ELOF5JT2zPavs95wbZ0BrLPrqvSZ7Ac+pjxCkmXtEQ@mail.gmail.com> (raw)
In-Reply-To: <CAExHW5v1Byk5PBB8o7A5iHgj9FcbzQDZQBCv-CoK89cV3dEbrg@mail.gmail.com>
References: <CALj2ACWh+hgE4U2W_zKUVLjLBaonyMCOKDEB6oFLP91y3AccWw@mail.gmail.com>
<CAExHW5v1Byk5PBB8o7A5iHgj9FcbzQDZQBCv-CoK89cV3dEbrg@mail.gmail.com>
On Mon, May 2, 2022 at 6:26 PM Ashutosh Bapat
<[email protected]> wrote:
>
> Hi Bharath,
>
>
> On Sat, Apr 30, 2022 at 11:08 AM Bharath Rupireddy
> <[email protected]> wrote:
> >
> > Hi,
> >
> > At times, there can be many temp files (under pgsql_tmp) and temp
> > relation files (under removal which after crash may take longer during
> > which users have no clue about what's going on in the server before it
> > comes up online.
> >
> > Here's a proposal to use ereport_startup_progress to report the
> > progress of the file removal.
> >
> > Thoughts?
>
> The patch looks good to me.
>
> With this patch, the user would at least know which directory is being
> scanned and how much time has elapsed.
There's a problem with the patch, the timeout mechanism isn't being
used by the postmaster process. Postmaster doesn't
InitializeTimeouts() and doesn't register STARTUP_PROGRESS_TIMEOUT, I
tried to make postmaster do that (attached a v2 patch) but make check
fails.
Now, I'm thinking if it's a good idea to let postmaster use timeouts at all?
> It would be better to know how
> much work is remaining. I could not find a way to estimate the number
> of files in the directory so that we can extrapolate elapsed time and
> estimate the remaining time. Well, we could loop the output of
> opendir() twice, first to estimate and then for the actual work. This
> might actually work, if the time to delete all the files is very high
> compared to the time it takes to scan all the files/directories.
>
> Another possibility is to scan the sorted output of opendir() thus
> using the current file name to estimate remaining files in a very
> crude and inaccurate way. That doesn't look attractive either. I can't
> think of any better way to estimate the remaining time.
I think 'how much work/how many files remaining to process' is a
generic problem, for instance, snapshot, mapping files, old WAL file
processing and so on. I don't think we can do much about it.
> But at least with this patch, a user knows which files have been
> deleted, guessing how far, in the directory structure, the process has
> reached. S/he can then take a look at the remaining contents of the
> directory to estimate how much it should wait.
Not sure we will be able to use the timeout mechanism within
postmaster. Another idea is to have a generic GUC something like
log_file_processing_traffic = {none, medium, high} (similar idea is
proposed for WAL files processing while replaying/recovering at [1]),
default being none, when set to medium a log message gets emitted for
every say 128 or 256 (just a random number) files processed. when set
to high, log messages get emitted for every file processed (too
verbose). I think this generic GUC log_file_processing_traffic can be
used in many other file processing areas.
Thoughts?
[1] https://www.postgresql.org/message-id/CALj2ACVnhbx4pLZepvdqOfeOekvZXJ2F%3DwJeConGzok%2B6kgCVA%40mail...
Regards,
Bharath Rupireddy.
Attachments:
[application/octet-stream] v2-0001-pgsql_tmp-ereport_startup_progress.patch (3.6K, ../CALj2ACW-ELOF5JT2zPavs95wbZ0BrLPrqvSZ7Ac+pjxCkmXtEQ@mail.gmail.com/2-v2-0001-pgsql_tmp-ereport_startup_progress.patch)
download | inline diff:
From 059099c469c40ee9d91a3b37b8960b36557e6030 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <[email protected]>
Date: Wed, 4 May 2022 14:17:24 +0000
Subject: [PATCH v2] pgsql_tmp ereport_startup_progress
---
src/backend/postmaster/postmaster.c | 11 +++++++++++
src/backend/storage/file/fd.c | 15 +++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 964a56dec4..261a5a5911 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -116,6 +116,7 @@
#include "postmaster/interrupt.h"
#include "postmaster/pgarch.h"
#include "postmaster/postmaster.h"
+#include "postmaster/startup.h"
#include "postmaster/syslogger.h"
#include "replication/logicallauncher.h"
#include "replication/walsender.h"
@@ -689,6 +690,11 @@ PostmasterMain(int argc, char *argv[])
pqsignal_pm(SIGXFSZ, SIG_IGN); /* ignored */
#endif
+ InitializeTimeouts(); /* establishes SIGALRM handler */
+
+ RegisterTimeout(STARTUP_PROGRESS_TIMEOUT,
+ startup_progress_timeout_handler);
+
/*
* Options setup
*/
@@ -1104,6 +1110,9 @@ PostmasterMain(int argc, char *argv[])
/* Write out nondefault GUC settings for child processes to use */
write_nondefault_variables(PGC_POSTMASTER);
+ /* Prepare to report progress of the temporary files removal phase */
+ begin_startup_progress_phase();
+
/*
* Clean out the temp directory used to transmit parameters to child
* processes (see internal_forkexec, below). We must do this before
@@ -1113,6 +1122,8 @@ PostmasterMain(int argc, char *argv[])
* conflicting Postgres processes in this data directory.
*/
RemovePgTempFilesInDir(PG_TEMP_FILES_DIR, true, false);
+
+ disable_timeout(STARTUP_PROGRESS_TIMEOUT, false);
#endif
/*
diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c
index 24704b6a02..c793303bd8 100644
--- a/src/backend/storage/file/fd.c
+++ b/src/backend/storage/file/fd.c
@@ -102,6 +102,7 @@
#include "storage/ipc.h"
#include "utils/guc.h"
#include "utils/resowner_private.h"
+#include "utils/timeout.h"
/* Define PG_FLUSH_DATA_WORKS if we have an implementation for pg_flush_data */
#if defined(HAVE_SYNC_FILE_RANGE)
@@ -3156,6 +3157,12 @@ RemovePgTempFiles(void)
DIR *spc_dir;
struct dirent *spc_de;
+ /*
+ * Prepare to report progress of the temporary and temporary relation files
+ * removal phase.
+ */
+ begin_startup_progress_phase();
+
/*
* First process temp files in pg_default ($PGDATA/base)
*/
@@ -3185,6 +3192,8 @@ RemovePgTempFiles(void)
FreeDir(spc_dir);
+ disable_timeout(STARTUP_PROGRESS_TIMEOUT, false);
+
/*
* In EXEC_BACKEND case there is a pgsql_tmp directory at the top level of
* DataDir as well. However, that is *not* cleaned here because doing so
@@ -3229,6 +3238,9 @@ RemovePgTempFilesInDir(const char *tmpdirname, bool missing_ok, bool unlink_all)
snprintf(rm_path, sizeof(rm_path), "%s/%s",
tmpdirname, temp_de->d_name);
+ ereport_startup_progress("removing temporary files under pgsql_tmp directory, elapsed time: %ld.%02d s, current file: %s",
+ rm_path);
+
if (unlink_all ||
strncmp(temp_de->d_name,
PG_TEMP_FILE_PREFIX,
@@ -3319,6 +3331,9 @@ RemovePgTempRelationFilesInDbspace(const char *dbspacedirname)
snprintf(rm_path, sizeof(rm_path), "%s/%s",
dbspacedirname, de->d_name);
+ ereport_startup_progress("removing temporary relation files under pg_tblspc directory, elapsed time: %ld.%02d s, current file: %s",
+ rm_path);
+
if (unlink(rm_path) < 0)
ereport(LOG,
(errcode_for_file_access(),
--
2.25.1
view thread (5+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Progress report removal of temp files and temp relation files using ereport_startup_progress
In-Reply-To: <CALj2ACW-ELOF5JT2zPavs95wbZ0BrLPrqvSZ7Ac+pjxCkmXtEQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox