Hi Tom,
 
Thank you for quick reply.
 
> 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.
Developer who debugs syslogger, probably, can remove fclose() calls.
Maybe we can have a switch for this?
As far as I understand there is no stdout printing in syslogger?
 
> Why is it a problem that we leave it open?
 
For us it's problem because logfiles are rotated by size.
The size of a file could be on order of few Gbs.
We can unlink logfile, logrotate is doing so, but the file will not be delete
form file system. We can use copy-truncate log rotation, this solves the problem,
but such solution seems outdated.
 
>  I don't believe either that the file will grow much (in normal cases anyway)
 
We are not in control of what user write to logs. We provide managed PostgreSQL.
Some users can set log_statement = 'all' and get tons of logs.
Our goal is to make logging system accountable to free space monitoring and
efficient (no log copy, no extra occupied space).
 
We could also avoid pointing pg_ctl log to same logfile as syslogger writes.
But that's how postgresql-common works and it is easier for our users to see
this output among usual logs to understand what was goining on with database.
 
> In any case, the proposed patch almost certainly introduces new
> problems, in that you dropped the fcloses's into code that
> executes repeatedly.
 
Probably, I should place fclose() right after successfull syslogger start?
 
_____
 
To reproduce problem on can follow this steps:
 
1) Use this settings:
log_destination = 'stderr,csvlog'
logging_collector = on 
log_filename = 'postgresql-11-data.log'
log_file_mode = '0640'   
log_truncate_on_rotation = off
 
2) pg_ctl -D DemoDb --log=/private/tmp/pg/postgresql-11-data.log start 
 
3) Check out open descriptors (look for types 1w - stdout and 2w - stderr)
lsof | grep postgres | grep log
postgres   7968 munakoiso    1w      REG                1,4        1170 3074156 /private/tmp/pg/postgresql-11-data.log
postgres   7968 munakoiso    2w      REG                1,4        1170 3074156 /private/tmp/pg/postgresql-11-data.log
postgres   7968 munakoiso   12w      REG                1,4        1170 3074156 /private/tmp/pg/postgresql-11-data.log
 
4) delete file /private/tmp/pg/postgresql-11-data.log to imitate logrotate, then
psql postgres -c "select pg_rotate_logfile();"
 
5) Check out open descriptors
without using this patch you shold find here lines with 1w and 2w
with using should not
 
lsof | grep postgres | grep log
postgres   8082 munakoiso    5w      REG                1,4        2451 3074156 /private/tmp/pg/postgresql-11-data.log
 
 
______________
Sviatoslav Ermilin
Yandex
 
 
12.09.2019, 18:33, "Tom Lane" <tgl@sss.pgh.pa.us>:

=?utf-8?B?0KHQstGP0YLQvtGB0LvQsNCyINCV0YDQvNC40LvQuNC9?= <munakoiso@yandex-team.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] https://salsa.debian.org/postgresql/postgresql-common/commit/580aa0677edc222ebaf6e1031cf3929f847f27fb</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