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