Hi,
On 2014-05-25 16:59:24 -0600, Jeff Ross wrote:
> Could a check like this be added to pg_upgrade?
> Is there a downside to
> adding a column big enough to force a toast table and then dropping it for
> any table that is too large not to have a toast table but doesn't?
It can take time and perm
On 5/25/14, 11:44 AM, Andres Freund wrote:
Hi,
On 2014-05-23 08:23:57 -0600, Jeff Ross wrote:
UDB=# \x
Expanded display is on.
UDB=# SELECT attrelid::regclass, attname, attnum, attlen, *
FROM pg_attribute
WHERE attrelid = 'masterairportlist'::regclass
ORDER BY attnum ASC;
UDB=#
[ RECORD 1 ]-+
Hi,
On 2014-05-23 08:23:57 -0600, Jeff Ross wrote:
> UDB=# \x
> Expanded display is on.
> UDB=# SELECT attrelid::regclass, attname, attnum, attlen, *
> FROM pg_attribute
> WHERE attrelid = 'masterairportlist'::regclass
> ORDER BY attnum ASC;
> UDB=#
> [ RECORD 1 ]-+--
> ...
A quic
On Fri, May 23, 2014 at 03:36:20PM +0200, Andres Freund wrote:
> On 2014-05-22 09:20:38 -0600, Jeff Ross wrote:
> > On 5/21/14, 2:37 PM, Bruce Momjian wrote:
> > >The only item I can think of that would cause this is someone changing
> > >the length of a string. Did someone modify pg_attribute dir
On Fri, May 23, 2014 at 08:32:35AM -0600, Jeff Ross wrote:
>
> On 5/23/14, 7:21 AM, 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 te
On 5/23/14, 7:21 AM, 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 jus
On 5/23/14, 7:36 AM, Andres Freund wrote:
Any chance you could, *before* you create the toast table, do a:
SELECT attrelid::regclass, attname, attnum, attlen, *
FROM pg_attribute
WHERE attrelid = 'a'::regclass
ORDER BY attnum ASC;
Where 'a' is replaced by the affected table?
Greetings,
Andr
On Thu, May 22, 2014 at 09:55:10AM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Moving forward, I think you need to add a dummy column to each problem
> > table and drop the column that will create a toast table and allow
> > you to do the upgrade. I could have pg_upgrade detect
On 2014-05-22 09:20:38 -0600, Jeff Ross wrote:
> On 5/21/14, 2:37 PM, Bruce Momjian wrote:
> >The only item I can think of that would cause this is someone changing
> >the length of a string. Did someone modify pg_attribute directly to
> >increase the length of one of the character columns?
> I d
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
On 5/21/14, 2:37 PM, Bruce Momjian wrote:
On Wed, May 21, 2014 at 04:23:34PM -0400, Tom Lane wrote:
Bruce Momjian writes:
On Wed, May 21, 2014 at 10:56:59AM -0600, Jeff Ross wrote:
Yes, using 9.3's pg_dump of 8.4 and applying it to both an 8.4 and a
9.3 cluster, the contact_email table now
Alvaro Herrera writes:
> Bruce Momjian wrote:
>> Moving forward, I think you need to add a dummy column to each problem
>> table and drop the column that will create a toast table and allow
>> you to do the upgrade. I could have pg_upgrade detect this problem, but
>> until I know the cause,
Bruce Momjian wrote:
> Moving forward, I think you need to add a dummy column to each problem
> table and drop the column that will create a toast table and allow
> you to do the upgrade. I could have pg_upgrade detect this problem, but
> until I know the cause, I don't think that is wise.
On Wed, May 21, 2014 at 04:37:13PM -0400, Bruce Momjian wrote:
> On Wed, May 21, 2014 at 04:23:34PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Wed, May 21, 2014 at 10:56:59AM -0600, Jeff Ross wrote:
> > >> Yes, using 9.3's pg_dump of 8.4 and applying it to both an 8.4 and a
> > >> 9
On Wed, May 21, 2014 at 04:23:34PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, May 21, 2014 at 10:56:59AM -0600, Jeff Ross wrote:
> >> Yes, using 9.3's pg_dump of 8.4 and applying it to both an 8.4 and a
> >> 9.3 cluster, the contact_email table now has toast in both 8.4 and
> >> 9.
Bruce Momjian writes:
> On Wed, May 21, 2014 at 10:56:59AM -0600, Jeff Ross wrote:
>> Yes, using 9.3's pg_dump of 8.4 and applying it to both an 8.4 and a
>> 9.3 cluster, the contact_email table now has toast in both 8.4 and
>> 9.3.
> So the big question is why doesn't the existing 8.4 table have
On Wed, May 21, 2014 at 10:56:59AM -0600, Jeff Ross wrote:
>
> On 5/21/14, 9:13 AM, Bruce Momjian wrote:
> >
> >On Wed, May 21, 2014 at 09:11:05AM -0600, Jeff Ross wrote:
> >>-- For binary upgrade, set heap's relfrozenxid
> >>UPDATE pg_catalog.pg_class
> >>SET relfrozenxid = '1944'
> >>WHERE oid =
On 5/21/14, 9:13 AM, Bruce Momjian wrote:
On Wed, May 21, 2014 at 09:11:05AM -0600, Jeff Ross wrote:
-- For binary upgrade, set heap's relfrozenxid
UPDATE pg_catalog.pg_class
SET relfrozenxid = '1944'
WHERE oid = 'contact_email'::pg_catalog.regclass;
-- For binary upgrade, set toast's relfroz
On Tue, May 20, 2014 at 10:25:44PM -0400, Bruce Momjian wrote:
> Find the table that is getting the toast file on the new cluster but not
> the old one, and run all the commands related to that table from the
> dump --- you don't need to load any data, just the schema items.
>
> Run that on the ol
On Tue, May 20, 2014 at 03:25:00PM -0600, Jeff Ross wrote:
> Here's a sample from a different database that failed with the same problem.
>
> Error: Mismatch of relation OID in database "UDB": old OID 1163225,
> new OID 22588
> postgres@vdev1commandprompt2:~$ psql "UDB"
> psql (9.3.4)
> Type "hel
On 5/20/14, 2:22 PM, Bruce Momjian wrote:
On Tue, May 20, 2014 at 12:59:31PM -0600, Jeff Ross wrote:
Removing support functions from new cluster ok
Copying user relation files
/var/lib/postgresql/8.4/main/base/4275487/4278965
Mismatch of relation OID in database "FNBooking":
On Tue, May 20, 2014 at 12:59:31PM -0600, Jeff Ross wrote:
> Removing support functions from new cluster ok
> Copying user relation files
> /var/lib/postgresql/8.4/main/base/4275487/4278965
> Mismatch of relation OID in database "FNBooking": old OID 4279499,
> new OID 19792
> Fail
Hi all,
I'm trying to pg_upgrade an 8.4.21 to 9.3.4.
The is on Debian 7--both versions were installed from apt.postgresql.org
and are encoding "UTF8" and locale "C".
Here's the error:
/usr/lib/postgresql/9.3/bin/pg_upgrade \
-b /usr/lib/postgresql/8.4/bin/ \
-B /usr/lib/post
23 matches
Mail list logo
