From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | MauMau <maumau307(at)gmail(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [bug fix] pg_ctl always uses the same event source |
Date: | 2013-12-10 03:30:46 |
Message-ID: | CAA4eK1+eBxc+qx8KaObYwcGAnkpygkP5_nrXtY1mat5xYPR6Kg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 9, 2013 at 5:52 PM, MauMau <maumau307(at)gmail(dot)com> wrote:
> From: "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>
>
>> 1. isn't it better to handle as it is done in write_eventlog() which
>> means if string is empty then
>> use PostgreSQL.
>> "evtHandle = RegisterEventSource(NULL, event_source ? event_source :
>> "PostgreSQL");"
>
>
> Thank you for reviewing. Yes, I did so with the first revision of this
> patch (see the first mail of this thread.) I wanted to avoid duplicating
> the default value in both the server and pg_ctl code. If user does not set
> event_source, postgres -C returns the default value "PostgreSQL" in the
> normal case, so I wanted to rely on it.
I think it is better to keep it like what I suggested above,
because in that case
it will assign default name even if postgres -C fails due to some reason.
>
>
>> 2. What will happen if user doesn't change the name in "event_source"
>> or kept the same name,
>> won't it hit the same problem again? So shouldn't it try to
>> generate different name by appending
>> version string to it?
>
>
> Yes, but I assume that the user has to set his own name to identify his
> instance uniquely. Even if version string is added, the same issue can
> happen --- in the likely case where the user explicitly installs, for
> example, PostgreSQL 9.3 as a standalone database, as well as some packaged
> application that embeds PostgreSQL 9.3 which the user is unaware of.
I mentioned it just to make sure that if such things can happen, it
is good to
either avoid it or document it in some way, so that user can
understand better
how to configure his system.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2013-12-10 03:31:15 | Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core |
Previous Message | Mark Kirkwood | 2013-12-10 03:13:17 | Re: ANALYZE sampling is too good |