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. 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.) 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.
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? This design cannot support that, and doesn't
need to AFAICS. 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 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?
Finally, I can tell without even trying it that the present syslogger
code will fail miserably in EXEC_BACKEND case. It's expecting
realStdErr to be inherited which it will not be. 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. (BTW, did Magnus ever verify for us that redirecting stderr
into a pipe will work at all on Windows? I think it should, but it
would be embarrassing to find out otherwise after we commit this
code...)
regards, tom lane