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',
'postgresql.conf.bak');
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.
Regards, Andreas
---------------------------(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
