Re: Current log files when rotating?

Sam Mason <sam(at)samason(dot)me(dot)uk> writes:

> On Mon, Nov 10, 2008 at 02:30:41PM -0800, Steve Atkins wrote:
>> On Nov 10, 2008, at 1:35 PM, Tom Lane wrote:
>> >Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> >>It seems that there is enough need for this feature, that it has been
>> >>implemented multiple times -- but most of them will fail in corner
>> >>cases. Seems an obvious candidate for an in-core function ...
>> >
>> >... which will still fail in corner cases. Not to mention the race
>> >condition when the logger has just/is about to switch.
>>
>> Also, it's going to be a fairly rare app that will need to both
>> look at the current logfile and access the database, so providing
>> visibility via a sql function seem clunky.
>
> Indeed, logfiles seem to be in a different world than from inside the
> database. It seems there are a couple of options; go and ask PG when
> you want to know (pg_ctl seems like a reasonable place IMHO) or have
> PG tell you when it's rotating logs, ala the current archiving of WAL
> files.
>
>> Maybe just have the logger maintain a symlink to the current
>> logfile,
>
> If used; a log archival program could do this.
>
>> or log to a static filename and only use a dynamically
>> generated filename when renaming the log file during rotation?
>
> However, this seems like a simpler solution altogether---no need to even
> ask as you know the answer already!
>
> This does still leave the question of whether there should be a log
> archival program around to tell you when they actually rotate. Going
> by the fact that people appear to cope with the current behavior, this
> just seems unnecessarily complicated and can reasonably be delayed for a
> while.

If I may revive this thread...

While generally sane and lightweight, the symlink approach still leaves
the chance for a race condition at the time of the switch.

What if we add an option for logging collector to duplicate every write
to the current file to a non-blocking fifo or something like that? This
seems to solve the problem of running "tail -f" against the current log
stream, which was the original request:

http://www.postgresql.org/message-id/Pine.GSO.4.64.0811101325260.9276@westnet.com

The fifo, however only allows for only one reader connection if I'm not
missing something.

--
Alex