Re: serverlog rotation/functions - Mailing list pgsql-hackers

Andreas Pflug wrote:
> 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.

Yes, the log file might contain SQL queries issued by others.  It is a
super-user only capability.

> > 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.

Huh?  Why have a default maximum?

> >>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.

Ah, I think it needs to close that as soon as it starts.  Don't other
subprocesses do that?  That shared memory is very fragile and we don't
want an errant pointer poking in there.

> > 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.

This seems clean and fast enough to me:
SELECT filenameFROM pg_dir_ls('/var/log')ORDER BY 1 DESCLIMIT 1

Considering that any query from a client is going to have to go through
the parser and be executed, an 'ls' in a directory just isn't a
measurable performance hit.

If you want run a test that does an 'ls' and one that doesn't to see
that there is no measurable performance difference.

I would not worry about the clock going backward.  PostgreSQL would have
enough problems with timestamp columns moving backward that the file log
times are the least of our problems.

> 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.

You can't know that you aren't reading corrupt data if you read shared
memory without a lock.  What if the write is happening as you read?

The only clean solution I can think of is to write an operating system
file that contains the current log filename and read from that.  I
believe such writes are atomic.  But again, this seems like overkill to
me.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073