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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, MauMau <maumau307(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [bug fix] pg_ctl always uses the same event source
Date: 2014-01-23 04:56:53
Message-ID: 30284.1390453013@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

[ shrug... ] But the same problem applies just as much to any attempt by
pg_ctl to know *any* postmaster parameter. In particular, this entire
patch is bogus, because the value it extracts from the postgresql.conf
file does not necessarily have anything to do with the setting the live
postmaster is actually using (which might be determined by a command-line
parameter or environment variable instead). If the technique could be
relied on, then it could be relied on just as much to extract the
postmaster's port setting.

I don't necessarily object to teaching pg_ctl to make a best-effort
estimate of a postmaster parameter in this way. But it's complete folly
to suppose that you can get an accurate value of event_source but not
the port number.

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. If we did
the latter then the problem would reduce to whether pg_ctl knows
the port number, which I think we're already assuming for other
reasons.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2014-01-23 05:27:09 Re: GIN improvements part 1: additional information
Previous Message KONDO Mitsumasa 2014-01-23 04:33:06 Re: Add min and max execute statement time in pg_stat_statement