Re: serverlog rotation/functions

Bruce Momjian wrote:
> Andreas Pflug wrote:
>>Just for convenience. Both start and size are optional parameters, but
>>with start=0 and size=50000. Well, it's a very special function anyway,
>>so we could require the user to supply all parameters. I'll remove it.
>
>
> Agreed, and maybe a zero value gets the entire file.

Which is a default param back again, maybe on a 100MB file? Better not.
Lets leave it to the admin to do sick stuff as
pg_read_file('base/5000/5002', 0, 100000000) ...

>
> No, I am thinking the program goes crazy and writes everywhere.

What I described was just that situation.

>>
> Yes, that is the usual method. We signal the postmaster and it then
> does the signalling to the logger. I thought you had looked at other
> backend signalling examples so I didn't explain it.

Well if you know the places where backends do signal stuff to the
postmaster... Still, somebody could have yelled "use the standard way
before reinventing the wheel".

>
> Now, one really good efficiency would be to use LISTEN/NOTIFY so clients
> could know when new data has appeared in the log, or the log file is
> rotated. Now that's an efficiency! However, let's get this
> infrastructure completed first. One wacky idea would be for the
> clients to LISTEN on 'pg_new_logfile' and have the logger do
> system('psql -c "NOTIFY pg_new_logfile" template1') or something like
> that.

No, certainly not. This would mean that every time a log is done, psql
is fired up. Tom wouldn't accept this as KISS, I believe. And h*ll, that
would cause traffic (just imagine a single log message on client startup...)

What you saw on LinuxTag was pgAdmin3 polling once a second if the
logfile length changed, which is the fastest setting possible.

Regards,
Andreas