Re: pg_upgrade improvements - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: pg_upgrade improvements
Date
Msg-id 20120405025846.GE1267@tamriel.snowman.net
Whole thread Raw
In response to pg_upgrade improvements  (Harold Giménez <harold.gimenez@gmail.com>)
Responses Re: pg_upgrade improvements  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Harold,

* Harold Giménez (harold.gimenez@gmail.com) wrote:
> Possible workarounds on the current version:

This has actually been discussed before and unfortunately there aren't
any trivial solutions.

> * Rewrite pg_hba.conf temporarily while the pg_upgrade script runs to
> disallow any other connections.

This is probably my favorite, from a 'practical' and 'effective'
standpoint.  I wonder if there'd be a way to specify the pg_hba.conf
to use on the command-line or in some other way, to avoid having to
actually modify the existing one (which would have to be 'unmodified'
after, of course..).

The other options would work, of course.  Perhaps my second favorite
option (second because I think it'd be more challenging and invasive) is
making the PG daemon only listens on a unix socket (which is not where
the default unix socket is).

The single-user option *sounds* viable, but, iirc, it actually isn't due
to the limitations on what can be done in that mode.

> It would also be nice if the invocation of pg_ctl didn't pipe its output to
> /dev/null. I'm sure it would contain information that would directly point
> at the root cause and could've saved some debugging and hand waving time.

Agreed.

> Finally, just a note that while we haven't performed a huge number of
> upgrades yet, we have upgraded a few production systems and for the most
> part it has worked great.

Great!
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: man pages for contrib programs
Next
From: Tom Lane
Date:
Subject: Re: pg_upgrade improvements