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?
[ 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