Re: pg_group_name_index corrupt?

Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I'd suggest not trying to restart the postmaster
>> automatically afterwards, though.  Too much site dependency in that.

> But doesn't it find the params from the last startup?

What last startup?  This may be a virgin database we're talking about
(probably would be, if I get my way about not using a postmaster at
all during pg_upgrade).  More to the point, people who are using
system-boot-time scripts to start postgres may expect their postmasters
to be started in a different environment than what pg_ctl would produce.
(Just because pg_ctl is available is not a good reason to assume that
people are using it, particularly not existing dbadmins who will have
developed their own procedures.)

The environment issue is potentially a pretty nasty gotcha; you'll
recall the problem reports we've heard in the past that turned out to
trace to different settings of LOCALE or whathaveyou between postmasters
started by hand and postmasters started by scripts.  Also, IIRC, pg_ctl
doesn't currently support sending the postmaster log anywhere but
/dev/null, which will annoy at least some people ;-).  One might also
guess that some sites run their postmasters with higher or lower process
priority than normal, or several other things that pg_ctl knows nothing
about.

So I think it's not really a good idea to wire use of pg_ctl into other
tools just yet.  Maybe after pg_ctl has been around for a few releases...

As I said, I see no harm in using pg_ctl to *stop* a postmaster, if it
can do that.  I just don't want to have it used automatically to
*start* one.
        regards, tom lane