On Mon, Jun 04, 2012 at 10:16:45AM -0400, Bruce Momjian wrote: > > I think the checks that are actually needed here are (1) bootstrap > > superusers are named the same, and (2) there are no roles other than the > > bootstrap superuser in the new cluster. > > You are right that it is more complex than I stated, but given the > limited feedback I got on the pg_upgrade/plplython, I figured people > didn't want to hear the details. Here they are: > > There are three failure modes for pg_upgrade: > > 1. check failure > 2. schema restore failure > 3. silent failure/corruption > > Of course, the later items are worse than the earlier ones. The > reporter got a "schema restore failure" while still following the > pg_upgrade instructions. My initial patch changed that #2 error to a #1 > error. Tom is right that creating users in the new cluster (against > instructions), can still generate a #2 error if a new/old pg_authid.oid > match, and they are not the install user, but seeing that is something > that is against the instructions, I was going to leave that as a #2.
Applied and back-patched to Postgres 9.1. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
