On Thu, Feb 25, 2016 at 1:15 AM, Euler Taveira <eu...@timbira.com.br> wrote: > On 02-02-2016 10:22, Armor wrote: >> As we known, the name of current log file depends on the number of >> seconds (for simple, later I will call it last_syslogger_file_time) >> since Epoch when create new log file. So, for this feature, the key is >> how syslogger process pass last_syslogger_file_time to backend processes. >> > I didn't like the name. Let's call it syslogger_file_name. It describes > what the variable is (actual file name that syslogger is writing on). > >> 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers