Re: pg_upgrade ?deficiency
От | Karsten Hilbert |
---|---|
Тема | Re: pg_upgrade ?deficiency |
Дата | |
Msg-id | trinity-20aaf552-08a5-43a3-88dc-0b9dc88b2b56-1385152047682@3capp-gmx-bs32 обсуждение исходный текст |
Ответ на | Re: pg_upgrade ?deficiency (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
> 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. I was the original poster on -users who raised this issue. Maybe I can clarify somewhat: I have been attempting to upgrade an 8.4 cluster to 9.1 by means of the 9.1 pg_upgrade command. That failed due to one of the databases in the 8.4 cluster being "ALTER DATABASE ... SET DEFAULT_TRANSACTION_READ_ONLY TO ON". Hence my question on that list whether that was to be considered a bug, a deficiency, or an oversight. I knew workarounds quite well but wondered whether that pg_upgrade behaviour was intended to stay that way. I suggested that if it is intended to stay it might benefit from a hint in the documentation. > Yeah, it's a minor issue at best, but perhaps worth fixing since > the solution is so easy. That would be really helpful. > The bigger picture here is that there are lots of ways to break > pg_upgrade via not-sane settings, and there always will be. Would setting default_transaction_read_only to on be considered non-sane ? If so, why ? > I don't think we should try to promise that there won't be. That last assertion is what everyone should certainly be able to agree with ;-) Thanks, Karsten
В списке pgsql-general по дате отправления: