Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Feb 25, 2016 at 1:15 AM, Euler Taveira <euler@timbira.com.br>>> wrote:
>>> To pass last_syslogger_file_time, we have 2 solutions: 1, add a
>>> global variable to record last_syslogger_file_time which shared by
>>> backends and syslogger, so backends can get last_syslogger_file_time
>>> very easily; 2 syslogger process send last_syslogger_file_time to pgstat
>>> process when last_syslogger_file_time changes, just as other auxiliary
>>> processes send stat message to pgstat process, and pgstat process will
>>> write last_syslogger_file_time into stat file so that backend can
>>> get last_syslogger_file_time via reading this stat file.
>> I prefer (1) because (i) logfile name is not statistics and (ii) stats
>> collector could not respond in certain circumstances (and even discard
>> some messages).
> (1) seems like a bad idea, because IIUC, the syslogger process doesn't
> currently touch shared memory. And in fact, shared memory can be
> reset after a backend exits abnormally, but the syslogger (alone among
> all PostgreSQL processes other than the postmaster) lasts across
> multiple such resets.
Yes, allowing the syslogger to depend on shared memory is right out.
I don't particularly care for having it assume the stats collector
exists, either -- in fact, given the current initialization order
it's physically impossible for syslogger to send to stats collector
because the former is started before the latter's communication
socket is made.
I haven't actually heard a use-case for exposing the current log file name
anyway. But if somebody convinced me that there is one, I should think
that the way to implement it is to report the actual *name*, not
components out of which you could reconstruct the name only by assuming
that you know everything about the current syslogger configuration and
the code that builds log file names. That's obviously full of race
conditions and code-maintenance hazards.
regards, tom lane
