Re: [GENERAL] pg_upgrade ?deficiency
От | Kevin Grittner |
---|---|
Тема | Re: [GENERAL] pg_upgrade ?deficiency |
Дата | |
Msg-id | 1385853668.15673.YahooMailNeo@web162902.mail.bf1.yahoo.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] pg_upgrade ?deficiency (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [GENERAL] pg_upgrade ?deficiency
Re: [GENERAL] pg_upgrade ?deficiency |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <bruce@momjian.us> writes: > >> I have fixed pg_upgrade in git-head with the attached patch, >> which prepends default_transaction_read_only=false to PGOPTIONS. > > What is the point of this, given that Kevin fixed pg_dumpall? > Don't those fixes take care of the issue? > > If your argument is that you want pg_upgrade to work even if the > user already turned on default_transaction_read_only in the *new* > cluster, I would humbly disagree with that goal, for pretty much > the same reasons I didn't want pg_dump overriding it. If there were databases or users with default_transaction_read_only set in the old cluster, the pg_dumpall run will cause that property to be set in the new cluster, so what you are saying seems to be that a cluster can't be upgraded to a new major release if any database within it has that set. My personal feeling is that it would be good if that were not a barrier to using pg_upgrade; but it would be OK as long as running it with the --check option *tells* you that the cluster can't be upgraded without turning that property off for all databases, and that the user under which it runs can't have the property set. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: