From: "Tom Lane" <t...@sss.pgh.pa.us>
"MauMau" <maumau...@gmail.com> writes:
I've encountered one problem on Windows. I need to support running all of
my
products on one host simultaneously. Plus, I need to log messages in
syslog/event log. On Linux, I can distinguish the messages of one product
and those of other products by setting syslog_ident in postgresql.conf.
On
the other hand, I can't do that on Windows: all of the PostgreSQL
instances
use the same fixed event source name "PostgreSQL".
SO I'd like to propose a trivial feature which allows users to set event
source.
I'm a bit concerned by the fact that this seems to require global
actions to be taken (registering/deregistering) when a GUC value
changes. That's going to cause headaches, not least because you cannot
assume that the value changes synchronously across all Postgres
processes. Maybe that's only an artifact of the way you worded this and
not a real requirement ... but if it is a requirement you should think
about how to avoid it. If you can't avoid it then most likely the event
name is going to have to be PGC_POSTMASTER, ie not changeable after
startup. Also, what happens if we fail to deregister because of
crashing?
Is it better to have one parameter for syslog program name and event
source,
instead of having both syslog_ident and event_source?
I don't like aliases for GUC variables, and in any case I think it'd be
confusing to force both usages to share a name that's not particularly
appropriate for either one alone. So personally, -1 for unifying those.
Others might see it differently though.
Considering Tom's advice, I'll make a patch as follows:
1. Create a new GUC variable called event_source and don't touch anything
with the existing syslog_ident.
2. Make event_source PGC_POSTMASTER at first because I don't think it is not
a requirement to change the event source name while PostgreSQL server is
active.
Also, what happens if we fail to deregister because of
crashing?
The registration/deregistration is performed separately from PostgreSQL's
start/stop, so there is no concern about this. Please see "Registering
eventlog on Windows" on the page below:
Installation Procedure
http://www.postgresql.org/docs/9.0/static/install-procedure.html
In fact, I've almost finished writing the program patch and testing.
However, I'd like to ask for your opinions about a few things before
completing and submitting the patch.
1. Documentation
Currently, the event Source registration is described on the above page.
However, many of my colleagues fail to find the article. They use
PostgreSQL as one of many software and don't fully read the manual.
I wonder if it would be better to put the article on the following section,
because this is in the chapter about installation on Windows:
16.1.4. Cleaning and installing
http://www.postgresql.org/docs/9.0/static/install-windows-full.html
or:
Post-Installation Setup
http://www.postgresql.org/docs/9.0/static/install-post.html
In addition, I think the above page should be linked from the description of
log_destination parameter.
2. pg_ctl's event logging
pg_ctl also logs to event log. Should pg_ctl use the event_source setting?
According to the response to the bug #6011 report, pg_ctl does not need to
obey the postgresql.conf setting, because postgresql.conf is for the server.
However, I'm afraid that the users claim that logging with event source
"PostgreSQL" instead of the event_source setting is a bug. For reference,
pg_ctl uses "port" parameter in postgresql.conf.
Regards,
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
