Robert Haas <robertmh...@gmail.com> writes: > On Thu, Feb 25, 2016 at 1:15 AM, Euler Taveira <eu...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers