On Tue, Jul 15, 2014 at 4:01 PM, MauMau <maumau...@gmail.com> wrote: > 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.
Well, it does in a couple of places. I'm nto sure it's that important (as nobody has AFAIK ever requested that change from for example EDB), but it's not a bad thing. However, with a hardcoded service name, I think the changes to pg_event.c are probably both not necessary and actually bad - as you'll now start getting errors in more harmless scenarios. >> 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". Oh, right. I see what you mean now. That goes for all parameters though, including -D, and we don't specify those as register mode only, so I still think it's wrong to place it there. It is now grouped with all other parameters that we specifically *don't* write to the commandline of the service. >> 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. Sure, no problem. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
