Re: serverlog rotation/functions

Now that I understand Andreas's patch, and the way he is using shared
memory to store only the timestamp, and how he checks shared memory on
every elog call, I no longer see problems with his method.

---------------------------------------------------------------------------

Tom Lane wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

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