Hi!
Few months ago we have encountered situation when some quite big open log files were open by Postres despite being deleted.
This affects free space caluculation in out managed PostgreSQL instances.
Currently I'm investigating this issue.
We traced some roots to unclosed descriptors in Perl code of postgresql-common [0], but we still face some unclosed descriptors pointing to log file.
Debian tools from postgresql-common starts pg_ctl piped to logfile. Descriptor is piped to logfile and block it for delete.
That is why we can't delete logfile.1 after logrotate.
And after second logrotate logfile.1 is in "deleted" status, but can't be deleted in fact.
Here I apply path with possible solution. In this patch stdout and stderr pipes are just closed in syslogger.
--
Sviatoslav Ermilin
Yandex
[0] https://salsa.debian.org/postgresql/postgresql-common/commit/580aa0677edc222ebaf6e1031cf3929f847f27fb
From ef44d999ce1d7dcfa515713e52d8b318d5f655af Mon Sep 17 00:00:00 2001 From: Ermilin Sviatoslav <ermili...@yandex.ru> Date: Thu, 12 Sep 2019 11:58:05 +0500 Subject: [PATCH] Close stderr and stdout in syslogger. Debian tools from postgresql-common starts pg_ctl piped to logfile. Descriptor is piped to logfile and block it for delete. That is why we can't delete logfile.1 after logrotate. And after second logrotate logfile.1 is in "deleted" status, but can't be deleted in fact.
--- src/backend/postmaster/syslogger.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/backend/postmaster/syslogger.c b/src/backend/postmaster/syslogger.c index 14d72d38d7..e23fa96c71 100644 --- a/src/backend/postmaster/syslogger.c +++ b/src/backend/postmaster/syslogger.c @@ -1365,6 +1365,9 @@ logfile_rotate(bool time_based_rotation, int size_rotation_for) if (csvfilename) pfree(csvfilename); + fclose(stdout); + fclose(stderr); + update_metainfo_datafile(); set_next_rotation_time(); -- 2.20.1 (Apple Git-117)