Re: serverlog rotation/functions

Bruce Momjian wrote:
> How is this patch supposed to work? Do people need to modify
> postgresql.conf and then sighup the postmaster? It seems more logical
> for the super-user to call a server-side function.

I assume calling pg_logfile_rotate() to be the standard way. calling
pg_logfile_rotate will increment the internal logfile timestamp, so each
backend's next write to the logfile will lead to a reopen. On the other
hand, if nothing is to be logged, nothing happens in the backends.

> You have
> pg_logfile_rotate(), but that doesn't send a sighup to the postmaster so
> all the backends will reread the global log file name.

As long as there's no SIGHUP, the logfile name template will not change,
so each backend can calculate the logfile's name from the timestamp. In
case a SIGHUP *is* issued, the template might have changed, so despite
an unchanged timestamp the filename to create might be different.
Additionally, SIGHUP will force all backends to check for current
logfile name, and close/reopen if their internal timestamp isn't
up-to-date with the common timestamp.

>
> Also, what mechanism is there to prevent backends from reading the log
> filename _while_ it is being modified?

I don't understand your concern. There's no place where the name is
stored, only the GUC log_filename which is actually the template, and
the timestamp (probably accessed atomically by the processor).
>
> Also there are no documenttion changes.

Hm, seems I missed this in this posting; the previous had it. I'll
repost it.

>
> However, looking at the issue of backends all reloading their
> postgresql.conf files at different times and sending output to different
> files,

We might have a fraction of a second in practice, when a SIGHUP was
issued to reread postgresql.conf, with a log_filename change, and a
backend still writing its log to the "old" log because GUC reread is
deferred for queries that started before SIGHUP. I don't really see a
problem with that.

I wonder if it would be best to create a log process and have
> each backend connect to that. That way, all the logging happens in one
> process.

<sigh> All I wanted was displaying the serverlog </sigh>

While this might be ultimately the best solution (we even might find a
way to catch stderr without interrupting further stderr piping),
currently this doesn't seem to be the right moment. We'd have several
inter process issues (and more with win32), which probably need some
discussion.
OTOH, if the current implementation is replaced by a log process later,
the api interface probably would stay the same.

Regards,
Andreas