Bruce Momjian wrote:
>>- 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