Re: pg_upgrade improvements

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: pg_upgrade improvements
Дата
Msg-id 20120405025846.GE1267@tamriel.snowman.net
обсуждение исходный текст
Ответ на pg_upgrade improvements  (Harold Giménez <harold.gimenez@gmail.com>)
Ответы Re: pg_upgrade improvements  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: man pages for contrib programs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_upgrade improvements