- How's the official way to restrict pg_* functions to superuser only
Very crudely :-)
Got it.
'nother question: Is reading the logfile a task that may be allowed to superusers only? I don't think so, though acls might apply.
Uh, that seems fine. You already check to see it is within the limit. I think a bigger question is should we limit it at all? Do we limit
pg_largeobject? Is that similar?
Ok, no limit (but a default maximum of 50k remains). And since it's superuser only, he hopefully knows what he does.
Very open question:
- How should a backend know the logger's pid if it's not in shmem. Write a magic string to the pipe?
I think it has to and in fact the pid is being written by the postmaster, not by the logger process, so that should be OK. The issue is that the logger shouldn't _attach_ to shared memory unless it has to.
It doesn't. It inherits the unnamed shared mem segment from the postmaster, as all subprocesses.
As far as recording the current log timestamp, I think that will be a problem. I would much rather see us forget about doing timestamp processing with these log files and keep it simple at this point and see what needs we have for 7.6.
I'm a bit insisting on this point. Remember, this all started from the attempt to display the serverlog on the client side. To do this, I need a way to retrieve the current logfile properties (size, and in case of rotation timestamp too) in a low-overhead way, or at least get to know something has changed. Scanning a whole directory and interpreting the data isn't low overhead any more.
There's no locking on the shmem, and the single dependence on shmem is the existence of it at the time of rotation. If the shmem is gone, postmaster is probably dead anyway.
Regards, Andreas
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
