Re: logfile subprocess and Fancy File Functions

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: logfile subprocess and Fancy File Functions
Date: 2004-07-23 21:40:38
Message-ID: 20040723141948.I55662@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


On Fri, 23 Jul 2004, Andreas Pflug wrote:

> > What we probably want instead is a separate
> > redirect_stderr_to_files boolean (I'm sure a better name could be
> > thought of).
> >
> > Also, while I'm aware that a superuser can persuade the backend to write
> > on anything, it doesn't follow that we should invent pg_file_write(),
> > pg_file_rename(), or pg_file_unlink(). Those are not needed for the
> > originally intended purpose of this patch
>
> I proposed to separate them, they're indeed non-related.
> What I'd like is
>
> SELECT pg_file_unlink('postgresql.conf.bak');
> SELECT pg_file_write('postgresql.conf.tmp', 'listen_addresses=...');
> SELECT pg_file_rename('postgresql.conf.tmp', 'postgresql.conf',
> 'postgresql.conf.bak');
> SELECT pg_reload_conf();

I personally don't think the above is the correct approach to allowing
configuration editing from remote. It seems like the wrong level for the
interface, and the file rename isn't atomic and pretending that it is may
prove to be dangerous.

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-07-23 21:48:26 Re: logfile subprocess and Fancy File Functions
Previous Message Tom Lane 2004-07-23 21:38:47 Re: Updated logging config (was: Initial eventlog support on win32 )