[HACKERS] Re: pg_upgrade fails: Mismatch of relation OID in database 8.4 - 9.3
Bruce Momjian wrote On Thu, May 22, 2014 at 09:20:38AM -0600, Jeff Ross wrote: I just tested ALTER TABLE in 8.4 and it does create a toast table for this case in 9.4: CREATE TABLE test (x CHAR(10)); ALTER TABLE test ALTER COLUMN x TYPE CHAR(8000); I just tried this on the problem table and it did indeed create a toast table. I then retried pg_upgrade and it failed with the same problem on a different table in the same database. Of the 67 databases in the 8.4 cluster, 5 (so far) have had this problem on at least one table. Yeah, it would be nice to be able to report all the problem tables, but I don't know how to do that except from pg_upgrade failing. Is there anything similar about these tables? Would a toast table in this situation have to be empty on the 8.4 database? Is there some kind of stat table query that would identify all such toast tables? Although it is possible some of those tables do indeed need a toast table but never make use of it (especially if one makes judicious use of unlimited text columns but never fills them with large amounts of data - like for lookup tables). David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/pg-upgrade-fails-Mismatch-of-relation-OID-in-database-8-4-9-3-tp5804593p5804793.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: pg_upgrade fails: Mismatch of relation OID in database 8.4 - 9.3
On Fri, May 23, 2014 at 06:28:28AM -0700, David G Johnston wrote: Bruce Momjian wrote On Thu, May 22, 2014 at 09:20:38AM -0600, Jeff Ross wrote: I just tested ALTER TABLE in 8.4 and it does create a toast table for this case in 9.4: CREATE TABLE test (x CHAR(10)); ALTER TABLE test ALTER COLUMN x TYPE CHAR(8000); I just tried this on the problem table and it did indeed create a toast table. I then retried pg_upgrade and it failed with the same problem on a different table in the same database. Of the 67 databases in the 8.4 cluster, 5 (so far) have had this problem on at least one table. Yeah, it would be nice to be able to report all the problem tables, but I don't know how to do that except from pg_upgrade failing. Is there anything similar about these tables? Would a toast table in this situation have to be empty on the 8.4 database? Is there some kind of stat table query that would identify all such toast tables? Although it is possible some of those tables do indeed need a toast table but never make use of it (especially if one makes judicious use of unlimited text columns but never fills them with large amounts of data - like for lookup tables). I don't see that as helping here. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: pg_upgrade
Whatever you guys decide is fine with me. Thomas Lockhart [EMAIL PROTECTED] writes: If it doesn't work, and will not be made to work, then let's remove it from the tree. I tend to agree with Peter's slightly less drastic proposal: remove it from the installed fileset and disable its man page, without necessarily 'cvs remove'ing all the source files. (I see we have already removed all the other documentation references to it, so disconnecting the ref page from reference.sgml should be sufficient.) I hope that pg_upgrade will be of use again in the future, so even though it can't work for 7.1, a scorched-earth policy is not the way to go... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: pg_upgrade
Since pg_upgrade will not work for 7.1, should its installation be prevented and the man page be disabled? Probably. I am not sure it will ever be used again now that we have numeric file names. Perhaps we should leave it for 7.1 because people will complain when they can not find it. Maybe we can mention this may go away in the next release. If it doesn't work, and will not be made to work, then let's remove it from the tree. If someone wants to resurrect it, then it is easily retrieved from the cvs attic. But istm that it is not a bad thing if people can not find something which will not work ;) Comments? - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: pg_upgrade
Thomas Lockhart [EMAIL PROTECTED] writes: If it doesn't work, and will not be made to work, then let's remove it from the tree. I tend to agree with Peter's slightly less drastic proposal: remove it from the installed fileset and disable its man page, without necessarily 'cvs remove'ing all the source files. (I see we have already removed all the other documentation references to it, so disconnecting the ref page from reference.sgml should be sufficient.) I hope that pg_upgrade will be of use again in the future, so even though it can't work for 7.1, a scorched-earth policy is not the way to go... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
