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
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
