Re: serverlog rotation/functions

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I saw Andreas demonstrating the viewing of server log files from pgadmin
> at Germany Linuxtag, and it certainly was impressive. However, for
> heavy, general usage, I don't think this patch is going to work.

That's my gut feeling as well.

> Probably the big thing this program was trying to solve was for the
> server to know the output file name, even with log file rotation, and I
> don't see a pipe and 'rotatelogs' process really addressing this.

It could be done. Given the infrastructure we have now, it's possible
to imagine the log capture process being a child of the postmaster that
can respond to GUC SIGHUPs (or forget that and just freeze the file name
pattern at PGC_POSTMASTER time, which isn't really that big a drawback).
You'd need the postmaster to create the pipe and then re-point its own
stdout and stderr at it, but that's doable on Unixen at least (I'm less
sure about Windows).

If the file names are timestamp-driven in any sane fashion then it's
easy enough to tell which is newest, so I don't think there is really a
need for shared memory communication between the log capture program and
the backends that want to grab some of the data. Just legislate that
the naming convention must generate names that sort ASCII-wise into
time order.

In this scenario the log capture process has robustness requirements
similar to the postmaster --- you really DO NOT want it to die, ever.
So the KISS principle applies. That means keep it away from shared
memory and try to minimize the number of signals it has to handle.
(This might be a good reason for treating all its config variables
as PGC_POSTMASTER; then it does not need to respond to SIGHUP.)

> It was also interesting to do the log rotate as a database call.

That struck me as not only useless but the deliberately hard way to do
it. To use that in the real world, you'd have to set up a cron job to
trigger the rotation, which means a lot of infrastructure and privilege;
whereas ISTM the point of this feature was to avoid both. The log
capture process should just do its own rotation on a pre-configured
time-interval basis, and/or maximum-file-size basis. I see zero value
added in having it respond to external signals.

I would like to have something like this in 7.5, but it's got to be
designed right. The patch as structured just feels all wrong to me...

> The only idea I have is for the postmaster to close its stderror the
> create a pipe to roatelogs and someone send all messages into there, and
> pass the file name from postgresql.conf to that rotatelogs program.

Right, pretty much the same thing I'm thinking.

regards, tom lane