Re: [GENERAL] pg_upgrade ?deficiency
От | Karsten Hilbert |
---|---|
Тема | Re: [GENERAL] pg_upgrade ?deficiency |
Дата | |
Msg-id | 20131128234601.GC11652@hermes.hilbert.loc обсуждение исходный текст |
Ответ на | Re: [GENERAL] pg_upgrade ?deficiency (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [GENERAL] pg_upgrade ?deficiency
|
Список | pgsql-hackers |
On Thu, Nov 28, 2013 at 10:39:18AM -0500, Bruce Momjian wrote: > Well, then we are actually using two different reasons for patching > pg_dumpall and not pg_dump. Your reason is based on the probability of > failure, while Tom/Kevin's reason is that default_transaction_read_only > might be used to block changes to a specific database, and they want a > pg_dump restore prevented, but a pg_dumpall restore to succeed. I can't really argue one way or another because *I* am not likely to be able to offer an actual patch. At any rate all I am interested in is that pg_upgrade does not fail to upgrade in surprising ways. Regarding restoring a pg_dump IMO the line would need to be drawn along the -c/--clean option because using such seems to clearly say that, yes, the user *wants* data to be deleted. If -C/--create is used it shouldn't matter ... However, I'm not saying that this is how it is to be done. I am well aware that drawing such subtle distinctions is walking quite a fine line. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
В списке pgsql-hackers по дате отправления: