Re: [bug fix] pg_ctl always uses the same event source - Mailing list pgsql-hackers
From | Amit Kapila |
---|---|
Subject | Re: [bug fix] pg_ctl always uses the same event source |
Date | |
Msg-id | CAA4eK1+wSAmVYeP4VmsLFw=cqmoNx-um+KgqrPXcFs5sD=iDKQ@mail.gmail.com Whole thread Raw |
In response to | Re: [bug fix] pg_ctl always uses the same event source (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: [bug fix] pg_ctl always uses the same event source
|
List | pgsql-hackers |
On Fri, Jan 24, 2014 at 2:38 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Jan 23, 2014 at 9:23 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> On Thu, Jan 23, 2014 at 10:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Amit Kapila <amit.kapila16@gmail.com> writes: >>>> On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>>> So? Anything which can know the value of a GUC parameter can certainly >>>>> know the selected port number. >>> >>>> 1. In case of registration of event source, either user has to pass the name >>>> or it uses hard coded default value, so if we use version number along with >>>> 'PostgreSQL', it can be consistent. >>>> I don't see any way pgevent.c can know port number to append it to default >>>> value, am I missing something here? >>> >>> >>> I think what we might want to do is redefine the server's behavior >>> as creating an event named after the concatenation of event_source >>> and port number, or maybe even get rid of event_source entirely and >>> just say it's "PostgreSQL" followed by the port number. >> >> To accomplish this behaviour, each time server starts and stops, >> we need to register and unregister event log using mechanism >> described at below link to ensure that there is no mismatch between >> what server uses and what OS knows. >> http://www.postgresql.org/docs/devel/static/event-log-registration.html > > Why wouldn't that be necessary with your approach, too? Because in my approach we are using compile time constant + #define DEFAULT_EVENT_SOURCE "PostgreSQL " PG_MAJORVERSION > I mean, if > there's a GUC that controls the event source name, then it can be > changed between restarts, regardless of what you call it. Yes, but not default values (when user don't provide any value for event_soource). Here the question is about default value of event_source. I will try to explain by example, focus of example is for case when user doesn't provide any value for event_source. The steps he needs to follow are as below: 1. initdb -D <data_dir> 2. regsvr32 <install_dir_path>\lib\pgevent32.dll 3. Modify postgresql.conf to set log_destination= 'eventlog' 4. pg_ctl.exe start -D <data_dir> Now for above, currently we use 'PostgreSQL' as default name for event source both during registration (step-2) and server start by pg_ctl (step-4). This will work fine, user will be able to see proper messages in event log (Windows EventViewer), however if user uses different versions on same m/c and follows above steps for both versions, then there is a chance (incase user unistall one of version), that EventViewer will not display PostgreSQL messages properly, it will show something like "event source not found". To resolve this case, we thought of appending version number to 'PostgreSQL' as a default name of event source. It might not work in all cases (for ex. 2 instances of same postgres version), but will work in many cases where currently it doesn't work. Now the problem for using port number is in step-2 of above case, currently pgevent.c has no way of knowing that port number value, let us say we teach in some way like MauMau said by passing parameter using /i option of regsvr32, but it might become confusing for user to use that option, because currently it is used for passing event source name (non-default case). If appending some compile time constant (if you have anything other than version number which is compile time const in your mind, that could also work equally easy) to default name doesn't sound to be viable fix for above problem, I think it is better to take that out of patch and may be it can be taken up as a separate patch. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
pgsql-hackers by date: