From: "Magnus Hagander" <mag...@hagander.net>
Is there a reason for there still being changes in guc.c, pgevent.c etc? Shouldn't it all be confined to pg_ctl now? That's my understanding from the thread that that's the only part we care about.
Yes, strictly speaking, those are useful for the original proposal. However, they are still useful as refactoring, since the current code has the default event source "PostgreSQL" in many places. Defining the default name only at one location would make it easier for vendors like EnterpriseDB to change the default name for their products. So I hope this will also be included if you don't want to reject it by all means.
More importantly, isn't it wrong to claim it will only be used for register and unregister? If we get an early failure in start, for example, there are numerous codepaths that will end up calling write_stderr(), which will use the eventlog when running as a service. Shouldn't the "-e" parameter be moved under "common options"?
Yes, you are right. -e is effective only if pg_ctl is invoked as a Windows service. So it is written at register mode. That is, -e specifies the event source used by the Windows service which is registered by "pg_ctl register".
I also think we should have the documentation specifically note that regular postgres output still goes to whatever the backend is configured to do. (and of course, any failure within the backend *before* we have parsed the config file for example will still go to the default source, and not the pg_ctl source - so we need to make it really clear that this is *only* for output from pg_ctl).
I see. I added this clarification to the description of -e. I would appreciate it if you could correct my poor English when committing, if it needs improvement.
Regards MauMau
pg_ctl_eventsrc_v10.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
