Tom Lane wrote:
Bruce Momjian wrote:

Are we done?

Nope, the syslogger part of this is still a mess.  I don't want any
pg_logfile_rotate() function in there at all: its presence is a hangover
from a different design philosophy.

No. As I mentioned earlier, there might be cases when a superuser wants to issue the rotation to keep some stuff in a single log file.

 Nor pg_reload_conf(); where did
that come from?  (Hint: if you can edit postgresql.conf you do not need
a helper function to signal the postmaster.)

Wrong. The generic file functions allow editing postgresql.conf without having file access, and consequently you'd like to make that active without consoling to the server.

 Nor the pg_logdir_ls view,
as that will malfunction completely if we aren't actually using the
syslogger facility, yet there's no graceful way to make it go away.

? It will show nothing if there are no files, so what's the problem?

I also find the Log_destination setup to be less than carefully thought
out: what in the world does it mean to specify stderr and file as
distinct log destinations?

stderr is simply untouched. Actually it works parallel.

This design cannot support that, and doesn't
need to AFAICS.

I didn't want to wipe out the default logging method right away. Of course, even log_destination=syslog might be redirected.

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',
SELECT pg_reload_conf();

and I think that they are just
invitations to trouble.  If you are aware that there are burglars out
there who know how to pick your door lock, do you then post directions
and tools to help on your door?

These are superuser only, and executed in the postgres user context. We're offering a superuser to shoot himself into the foot wherever he likes regarding system catalog etc. I wouldn't have a problem if paths may only be relative to PG_DATA and .. is disallowed.

Finally, I can tell without even trying it that the present syslogger
code will fail miserably in EXEC_BACKEND case.

I don't have an EXEC_BACKEND environment, I already pointed out that this has to be tested.

It's expecting
realStdErr to be inherited which it will not be.

Yes, this is probably one source of problems for EXEC_BACKEND.

I don't think the
notion of respawning the logger will work; we're just going to have to
assume it is as reliable as the postmaster is, and we only need launch
it once.

It works.

(BTW, did Magnus ever verify for us that redirecting stderr
into a pipe will work at all on Windows?

Actually, dup2 etc is documented perfectly for win32. This certainly doesn't mean anything...
win32 system error messages are retrieved using GetLastError, not from stderr, so problems are a bit different anyway.


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
     subscribe-nomail command to [EMAIL PROTECTED] so that your
     message can get through to the mailing list cleanly

Reply via email to