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
