Re: [GENERAL] pg_upgrade ?deficiency
От | Kevin Grittner |
---|---|
Тема | Re: [GENERAL] pg_upgrade ?deficiency |
Дата | |
Msg-id | 1385508344.12244.YahooMailNeo@web162905.mail.bf1.yahoo.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] pg_upgrade ?deficiency (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [GENERAL] pg_upgrade ?deficiency
Re: [GENERAL] pg_upgrade ?deficiency |
Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> wrote: > How are we handling breakage of pg_dump, not pg_dumpall? That was discussed. Do you have something to add? > doc patch? Instead of the fix you mean, or with it? I don't see what we would change in the docs for the fix; the alternative might be to document that pg_dumpall output will fail to restore if any database (or the restoring user) has this property set. > pg_upgrade probably needs a doc patch too, or a reset like > pg_dumpall. pg_upgrade is more like pg_dumpall, so a code patch > seems most logical, again, assuming we decide that pg_dumpall is > the right place for this reset of default_transaction_read_only. I don't have much opinion on what the pg_upgrade aspect except, like I said, that if it is going to fail, it should fail in the check. Passing the check but failing during the upgrade would not be very user-friendly. Again, I'm not sure that a doc patch is needed to say that pg_upgrade works even when this option is set. Why would anyone assume otherwise? Why would we list this property and not others? I'm willing to do the pg_dumpall patch but would rather not take on pg_upgrade. If you would rather I leave the whole thing to you, that's OK, too. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: