Re: Feature proposal: distinguish each PostgreSQL instance in the event log - Mailing list pgsql-hackers

From: "Tom Lane" <tgl@sss.pgh.pa.us>
> "MauMau" <maumau307@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