Re: pg_upgrade ?deficiency

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_upgrade ?deficiency
Дата
Msg-id 20131122210930.GB23961@momjian.us
обсуждение исходный текст
Ответ на Re: pg_upgrade ?deficiency  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On Fri, Nov 22, 2013 at 03:13:33PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Not sure about backpatching.  default_transaction_read_only has been
> > around since 7.4.  Setting it to true would cause pg_dump to fail unless
> > you changed the database setting, and pg_dumpall would fail completely
> > as there is no way to turn off the database setting.
>
> No, neither pg_dump nor pg_dumpall would fail.  What would fail is
> restoring into a database that has this option already set.  It's possible
> that users of this option haven't noticed it because they never attempted
> a restore in such a context.

Well, pg_dumpall is going to restore that setting before putting any
data in the database, so it will fail.  I have tested that, and also
tested that PGOPTIONS fixes it.

> > The problem is that I don't remember any report of this failing in
> > pg_dump, pg_dumpall, or pg_upgrade, so saying it is a major issue is
> > hard to accept.
>
> Yeah, it's a minor issue at best, but perhaps worth fixing since
> the solution is so easy.

Yes.

> The bigger picture here is that there are lots of ways to break
> pg_upgrade via not-sane settings, and there always will be.
> I don't think we should try to promise that there won't be.

So document PGOPTIONS in pg_upgrade?

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +


В списке pgsql-general по дате отправления:

Предыдущее
От: Juan Daniel Santana Rodés
Дата:
Сообщение: Recursive function
Следующее
От: David Johnston
Дата:
Сообщение: Re: Recursive function