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 по дате отправления: