Re: serverlog rotation/functions

Andreas Pflug wrote:
> 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.

Oh, I remember now. You had explained it in a previous email. Only the
timestamp is saved in global memory (not the name). Each backend,
before writing, checks the global and reopens if needed. I see the
LogFileCheckReopen() call in elog.c now, and that is the key to the
whole thing. Sorry I got confused.

One question, you open the logfile in a+ (append/read). Isn't "a" alone
correct?

> > 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.

Sounds good. I get it now.

> >
> > 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.

You are right. Each backend reads the postgresql.conf file itself so
there is not a real problem except for backends that are delayed
rereading. I don't see that as a huge problem because if you change the
postgresql.conf to log to a different file location (file name aleady
changes with reload call to be current time), you should expect a delay.
The rotate is pretty fast.

> 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.

OK, I withdraw my concerns. It looks quite interesting (with docs you
already have).

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073