Re: Close stdout and stderr in syslogger

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Святослав Ермилин <munakoiso(at)yandex-team(dot)ru>
Cc: Дмитрий Сарафанников <dsarafan(at)yandex-team(dot)ru>, Андрей Бородин <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Close stdout and stderr in syslogger
Date: 2019-09-12 13:32:54
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

=?utf-8?B?0KHQstGP0YLQvtGB0LvQsNCyINCV0YDQvNC40LvQuNC9?= <munakoiso(at)yandex-team(dot)ru> writes:
> <div><div>Hi!</div><div> </div><div>Few months ago we have encountered situation when some quite big open log files were open by Postres despite being deleted.</div><div>This affects free space caluculation in out managed PostgreSQL instances.</div><div>Currently I'm investigating this issue.</div><div>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.</div><div> </div><div>Debian tools from postgresql-common starts pg_ctl piped to logfile. Descriptor is piped to logfile and block it for delete.</div><div>That is why we can't delete logfile.1 after logrotate.</div><div>And after second logrotate logfile.1 is in "deleted" status, but can't be deleted in fact.</div><div> </div><div>Here I apply path with possible solution. In this patch stdout and stderr pipes are just closed in syslogger.</div><div> </div><div>--</div><div>Sviatoslav Ermilin</div><div>Yandex</div><div> </div><div>[0]</div></div>

I'm quite certain that the current behavior is intentional, if only
because closing the syslogger's stderr would make it impossible to
debug problems inside the syslogger. Why is it a problem that we
leave it open? I don't believe either that the file will grow much
(in normal cases anyway), or that it's impossible to unlink it
(except on Windows, but you didn't say anything about Windows).

In any case, the proposed patch almost certainly introduces new
problems, in that you dropped the fcloses's into code that
executes repeatedly.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-09-12 13:35:15 Re: SegFault on 9.6.14
Previous Message Alexander Korotkov 2019-09-12 13:18:07 Re: doc: pg_trgm missing description for GUC "pg_trgm.strict_word_similarity_threshold"