Re: get current log file

I think I know what you are concerned about. May be I did not explain my solution very clearly.

(i) Using a variable named last_syslogger_file_time replace first_syslogger_file_time in syslogger.c. When postmaster initialize logger process,   last_syslogger_file_time will be assign the time stamp when logger start, then fork the child process for logger. Later logger will create a log file based on last_syslogger_file_time . And   last_syslogger_file_time in the postmaster process will be inherited by other  auxiliary processes 

(ii) when pgstat process initialize, it will read  last_syslogger_file_time from pg stat file of last time (because pgstat process will write it to pg stat file). And then pgstat process will get last_syslogger_file_time inherit from postmaster,  if this version of  last_syslogger_file_time is larger then that read from the stat file, it means logger create a new log file so use it as the latest value; else means pgstat process crashed before, so it need to use the value from stat file as the latest.

(iii) when logger rotate a log file, it will assign time stamp to last_syslogger_file_time  and send it to pg_stat process. And pg_stat process will write last_syslogger_file_time to stat file so can be read by other backends.

(iiii) Adding a stat function named pg_stat_get_log_file_name, when user call it, it will read  last_syslogger_file_time from stat file and construct the log file name based on log file name format and last_syslogger_file_time, return the log file name eventually.

 

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