Re: [bug fix] pg_ctl always uses the same event source

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [bug fix] pg_ctl always uses the same event source
Дата
Msg-id CAA4eK1+wSAmVYeP4VmsLFw=cqmoNx-um+KgqrPXcFs5sD=iDKQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [bug fix] pg_ctl always uses the same event source  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [bug fix] pg_ctl always uses the same event source  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Change authentication error message (patch)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Why do we let autovacuum give up?