pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedBack to my pg_upgrade stoppage problem
3+ messages / 2 participants
[nested] [flat]
* Back to my pg_upgrade stoppage problem
@ 2015-01-16 15:56 John Scalia <jayknowsunix@gmail.com>
2015-01-22 03:46 ` Re: Back to my pg_upgrade stoppage problem Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 3+ messages in thread
From: John Scalia @ 2015-01-16 15:56 UTC (permalink / raw)
To: pgsql-admin
Hi all,
I'm back to trying to figure out the pg_upgrade stoppage problem on my V9.4.0 upgrade from V9.3.3. As stated earlier, my environment is CentOS 6.5 kernel and the server is
virtualized, but has been running 9.3.3 for some time now. I ran pg_upgrade on this system as follows, I apologize for the length of the message but I putting the entire screen
capture into this. You can see at the end that it got hung up trying to create a temporary table, but the server has been on this step for nearly an hour now. It had successfully
performed several queries prior to this, and those were successful.
[ postgres@csgha2] /usr/pgsql-9.4/bin/pg_upgrade -b /usr/pgsql-9.3/bin -B /usr/pgsql-9.4/bin -d /var/lib/pgsql/9.3/data -D /var/lib/pgsql/9.4/data -v
Running in verbose mode
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
pg_control values:
First log segment after reset: 000000080000004200000034
pg_control version number: 937
Catalog version number: 201306121
Database system identifier: 5999528689196325886
Latest checkpoint's TimeLineID: 8
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0/3223
Latest checkpoint's NextOID: 42583
Latest checkpoint's NextMultiXactId: 2
Latest checkpoint's NextMultiOffset: 0
Latest checkpoint's oldestXID: 1798
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 3222
Latest checkpoint's oldestMultiXid: 1
Latest checkpoint's oldestMulti's DB: 0
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 1996
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by value
Data page checksum version: 0
Current pg_control values:
pg_control version number: 942
Catalog version number: 201409291
Database system identifier: 6104926301746638117
Latest checkpoint's TimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0/1810
Latest checkpoint's NextOID: 13004
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Latest checkpoint's oldestXID: 1800
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 0
Latest checkpoint's oldestMultiXid: 1
Latest checkpoint's oldestMulti's DB: 1
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 1996
Size of a large-object chunk: 2048
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by value
Data page checksum version: 0
Values to be changed:
First log segment after reset: 000000010000000000000002
"/usr/pgsql-9.3/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/pgsql/9.3/data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c
unix_socket_directories='/var/lib/pgsql/9.4/data'" start >> "pg_upgrade_server.log" 2>&1
executing: SELECT datcollate, datctype FROM pg_catalog.pg_database WHERE datname = 'template0'
executing: SELECT pg_catalog.pg_encoding_to_char(encoding) FROM pg_catalog.pg_database WHERE datname = 'template0'
executing: SELECT c.relname, c.relfilenode FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n WHERE c.relnamespace = n.oid AND n.nspname = 'pg_catalog'
AND c.relname = 'pg_database' ORDER BY c.relname
executing: SELECT d.oid, d.datname, pg_catalog.pg_tablespace_location(t.oid) AS spclocation FROM pg_catalog.pg_database d LEFT OUTER JOIN pg_catalog.pg_tablespace t ON
d.dattablespace = t.oid WHERE d.datallowconn = true ORDER BY 2
executing: CREATE TEMPORARY TABLE info_rels (reloid) AS SELECT c.oid FROM pg_catalog.pg_class c JOIN pg_catalog.pg_namespace n ON c.relnamespace = n.oid LEFT OUTER JOIN
pg_catalog.pg_index i ON c.oid = i.indexrelid WHERE relkind IN ('r', 'm', 'i', 'S') AND i.indisvalid IS DISTINCT FROM false AND i.indisready IS DISTINCT FROM false AND
((n.nspname !~ '^pg_temp_' AND n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema', 'binary_upgrade', 'pg_toast') AND c.oid >=
16384) OR (n.nspname = 'pg_catalog' AND relname IN ('pg_largeobject', 'pg_largeobject_loid_pn_index', 'pg_largeobject_metadata', 'pg_largeobject_metadata_oid_index') ));
Thanks in advance,
Jay
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Back to my pg_upgrade stoppage problem
2015-01-16 15:56 Back to my pg_upgrade stoppage problem John Scalia <jayknowsunix@gmail.com>
@ 2015-01-22 03:46 ` Bruce Momjian <bruce@momjian.us>
2015-01-22 13:59 ` Re: Back to my pg_upgrade stoppage problem John Scalia <jayknowsunix@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Bruce Momjian @ 2015-01-22 03:46 UTC (permalink / raw)
To: John Scalia <jayknowsunix@gmail.com>; +Cc: pgsql-admin
On Fri, Jan 16, 2015 at 10:56:19AM -0500, John Scalia wrote:
> Hi all,
>
> I'm back to trying to figure out the pg_upgrade stoppage problem on
> my V9.4.0 upgrade from V9.3.3. As stated earlier, my environment is
> CentOS 6.5 kernel and the server is virtualized, but has been
> running 9.3.3 for some time now. I ran pg_upgrade on this system as
> follows, I apologize for the length of the message but I putting the
> entire screen capture into this. You can see at the end that it got
> hung up trying to create a temporary table, but the server has been
> on this step for nearly an hour now. It had successfully performed
> several queries prior to this, and those were successful.
I suggest you upgrade to V9.3.5 at a minimum. Second, try the why on
its own to see if it works.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Back to my pg_upgrade stoppage problem
2015-01-16 15:56 Back to my pg_upgrade stoppage problem John Scalia <jayknowsunix@gmail.com>
2015-01-22 03:46 ` Re: Back to my pg_upgrade stoppage problem Bruce Momjian <bruce@momjian.us>
@ 2015-01-22 13:59 ` John Scalia <jayknowsunix@gmail.com>
0 siblings, 0 replies; 3+ messages in thread
From: John Scalia @ 2015-01-22 13:59 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-admin
I did manage to get everything working properly yesterday. What I did not first realize is that while pg_upgrade requires both the original server and the new one to be off, if
your original server is the primary in a streaming replication cluster, then the standby(s) must still be running when you start pg_upgrade. The temporary table creation appeared
hung as the primary was waiting on the standby to commit the change, but it wasn't running. After resolving that, I hit another snag where pgpool had a function installed that I
couldn't easily find to remove it. pg_upgrade would fail stating it couldn't find the function's *.so to apply to the new instance. I ended up pulling a pg_dumpall from the
original instance, and manually looked in that to find anything with the name pgpool in it. I then removed those from the Db, and pg_upgrade completed successfully.
Thanks to everyone for their assistance. I just needed to think a little harder on what was happening.
On 1/21/2015 10:46 PM, Bruce Momjian wrote:
> On Fri, Jan 16, 2015 at 10:56:19AM -0500, John Scalia wrote:
>> Hi all,
>>
>> I'm back to trying to figure out the pg_upgrade stoppage problem on
>> my V9.4.0 upgrade from V9.3.3. As stated earlier, my environment is
>> CentOS 6.5 kernel and the server is virtualized, but has been
>> running 9.3.3 for some time now. I ran pg_upgrade on this system as
>> follows, I apologize for the length of the message but I putting the
>> entire screen capture into this. You can see at the end that it got
>> hung up trying to create a temporary table, but the server has been
>> on this step for nearly an hour now. It had successfully performed
>> several queries prior to this, and those were successful.
> I suggest you upgrade to V9.3.5 at a minimum. Second, try the why on
> its own to see if it works.
>
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2015-01-22 13:59 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2015-01-16 15:56 Back to my pg_upgrade stoppage problem John Scalia <jayknowsunix@gmail.com>
2015-01-22 03:46 ` Bruce Momjian <bruce@momjian.us>
2015-01-22 13:59 ` John Scalia <jayknowsunix@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox