Message-ID: <5053F896.60005@gmail.com>
Date: Sat, 15 Sep 2012 11:40:06 +0800
From: Rural Hunter <ruralhunter@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Bruce Momjian <bruce@momjian.us>
CC: pgsql-admin@postgresql.org
Subject: Re: pg_upgrade from 9.1.3 to 9.2 failed
References: <5052C402.8020003@gmail.com> <20120914142616.GA11265@momjian.us>
	<50535302.8080000@gmail.com> <20120914183915.GA5933@momjian.us>
In-Reply-To: <20120914183915.GA5933@momjian.us>
Content-Type: multipart/mixed; boundary="------------080003010508000703060303"

This is a multi-part message in MIME format.
--------------080003010508000703060303
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

于 2012/9/15 2:39, Bruce Momjian 写道:
> On Fri, Sep 14, 2012 at 11:53:38PM +0800, Rural Hunter wrote:
>>>> Performing Upgrade
>>>> ------------------
>>>> Analyzing all rows in the new cluster                       ok
>>>> Freezing all rows on the new cluster                        ok
>>>> Deleting files from new pg_clog                             ok
>>>> Copying old pg_clog to new server                           ok
>>>> Setting next transaction ID for new cluster                 ok
>>>> Resetting WAL archives                                      ok
>>>> Setting frozenxid counters in new cluster                   ok
>>>> Creating databases in the new cluster                       ok
>>>> Adding support functions to new cluster                     ok
>>>> Restoring database schema to new cluster                    ok
>>>> Removing support functions from new cluster                 ok
>>>> Copying user relation files
>>>>    /raid/pgsql/base/6087920/6088238
>>>> old and new databases "testdb" have a different number of relations
>>>> Failure, exiting
>>> That is an odd failure.  That check was added in PG 9.1 and this is the
>>> first time I am seeing this failure.
>>>
>>> The check is to make sure that once we have created all the user schema
>>> details in the new cluster, that there are the same number of objects in
>>> the new and old databases.
>>>
>>> Obviously there are a different number in your case here, but I don't
>>> know why those would be different, and in fact, because we have never
>>> hit this, there isn't even any debug output that shows the source of the
>>> difference.
>>>
>>> If I send you a patch can you compile it and send back the debug output
>>> it produces?
>>>
>> Yes sure, I will try to compile and retest with it.
> Actually, I have a simpler idea.  At the point where it fails, you can
> run pg_dump --schema-only on the testdb database in the old and new
> cluster and then diff those output files and email the result to us;  it
> should show the mismatch.  I am not sure if the dumps will output the
> objects in the same order, it might.
>
diff attached.

--------------080003010508000703060303
Content-Type: application/x-zip-compressed;
 name="schmdiff.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="schmdiff.zip"

UEsDBBQAAAAIAMlcL0He/lsEYQYAAPRMAAAMAAAAc2NobWRpZmYub3V01Ztbr5NAFIXf/RW8
qYkm3AZKNSZen6omXh58mkxhbFEGEAaPx1/v3thj2ylUpgEyTbSantl8a9FhWLMPJa4dxfhy
76n1fPXp9Qfr0/MXq9cWyxn9zm9viirZvf/y/erz23fW9zSxPr7+ZL16/eb559UnK+e/5E+W
Pbh/UEFhEK35j/vLZcU3ccbq+uGTe48fP7737Ajy/t3qyxQk4jpBjC+PSBD4qrNKpnHGj1ms
j7UbTZmOo/EIz6y/fwCEL9Y7JvgSj/XE+nRbwn93h3tifYy3XLClVTbrLI2fWO9vcl4trbrJ
f2+buyOcUUvXWbGZTnItbzM+h+gWdCTb7tNUzHQekTNM0XoeQeuhepoqm0MPYI70vPu8Wi2X
6zLesqr3GmjktqjmUPeXpC1QpnKeGd+CtOVtWb2lZcbSfA6Ne5q20NYexQPMIXRP0xa6aea5
epGjLS7nG1oW9Rz6dqhhK4xgMt7SuEhmuVT+0fSvl1qyzSwaETTwBlaV2S2NGzmHrDvWQGWc
JbMpA9ZwZXUVzyEKMMP0TJJBvhZVI64uzLWqDUtzrSaj4lyryKQ81woyN9C18kxOdK1A0yNd
K/IqMl2r1PBQ12o0OdW1Ag2Nda0203NdK9LAYNfqMjPZtdKMi3atKpOynbjKRp0wsFMnjGvV
CdN6dcLsZp0wvVsnrqFdJ66mXyeuoGEnTO/YCYNbduIaenbC0KadMLdrJ4xs2wnT+nY5v6mv
LtqhaMOSHUoyKtihIJNyHeoxN9ahOpNTHeozPdShxqvIdCjU8EiHEk1OdKjP0ECH0kzPc6jR
wDiHssxMc6jMuDCHov6b5YjrejEJQqf7oUBacTjFirUzCWxfQyv9BwTHphHXs9HcQjGHKXfD
K1o01fkQsqcdltC1hrVJWGAsBGMLohorWJUMpeBYPSvjHJ24vg/iI7dLPHVOAM45gkNxhJ6F
sRjEJQ4aUR8VjgtRslyZx3HfmdqNprHGJzEiAUwsYhLaQbcJWqdSeXC3H7OvoPpmxiQRNyBg
yvEUUwmTrKyK+BiT9XHuhtNMw86oDOKGLhhxbdUIL2H9EzyXA+fAvkBroo3OAUMRGgpPDUkq
4Q6oJN8+zr/xVOrZGZNC3EUAZjz1ifqvdZkmsIDDOj5wFhxUaE22CUjEjTww5auJQO8rCZd8
8WFEAvFsG02od/67ItYkqRy22ByV6Kxrk7DAWAjGiHrnz9iaZwOnQDtWa5qNdHTiOT6ID9wu
8ZrfeWlrLvp+zUQ04rkOmlPTgOB1DZsnZc/XB9qNpkLD0IgEMIFpIAy6TdByW+QKqP4vqS2i
9QWWxucRz8NksPDOGaQsSSp4Q7nnNcPAu2LY/V1qeEo+8XxMFJGaKPJCpl9v6TatlbUq76Me
VNBcw+oEJDAVoSk1VRQlr5gsqiMOvNsHuhtPi1LD0MgU4hFIFQvb7zFDd/F32C1FrdK5g01I
JF7ggUlHTRllHNO65HHKMhoLqVz6vadUKaO1zuc3KZN4oY1G1SRSFRkf2OnAoVrtlFGODcJD
EO4SVTguLVuW52oiiLe9kH0J/KtjZAoW8RY+GPPcU2N9aRreOMPbV+FfPXtTEYkXOWhSTSM1
ZxV0m3m+SfOBu+3DEq2N/SQsMLYAY76aULAXoLO1w/H6G8iRKcS3CZghXoeZC2YGlv1/anRb
m5ZJfMcFo4GaOiSrv1MWy7TIh02QgwKdqTg6BwxFaCjsN6QzTw7K9CflpEziu5hGQr/LaMwk
3xTVrULs7Q4dFVGp04majEd8D5PIwukymHDJ0kzBJb24fQmVia65sVnE9200tugyBuNOrgXZ
mxIOSqjUSSKTsMAYJpOIdBmD31TKpu7YXfQmBrWM6iSUSZnEJ5BUIltNKk2Nq+1pT6bpbcrs
K2ij0/iZgET8wEFTUYcp9RGcsxCd7fU4BwfpC5DuqNnjJy8YxbKBhHa8toeRKcQPCZhx1exx
w6o8zTeaDbJd1UUNuQmJxF+4YNKze0xWjbpTuuldmA5r6I3OKjgRDcxFaC5UzfH16e/SvvaB
dqPpVx1D4xGIHwVgwvdPTeiGbSi5LNVPwiLExuvrJNt/YxXsb6QaYtq3+mj/av6+alibiEaI
g9dVYJ+awwcyCjg3akzDn50j7svoN6ZzdU3KBKN4jZ3kfPzcBSu7zi283cc8qqKC6XSpJiT+
AVBLAQI/ABQAAAAIAMlcL0He/lsEYQYAAPRMAAAMACQAAAAAAAAAIAAAAAAAAABzY2htZGlm
Zi5vdXQKACAAAAAAAAEAGAByVPKK85LNARpg44rzks0BGmDjivOSzQFQSwUGAAAAAAEAAQBe
AAAAiwYAAAAA
--------------080003010508000703060303--