Amit Kapila <amit.kapil...@gmail.com> writes: > On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers