On Thu, Mar 01, 2012 at 09:06:10PM -0500, Bruce Momjian wrote:
> OK, combining your and Robert's ideas, how about I have pg_upgrade write
> the server log to a file, and the pg_dump output to a file (with its
> stderr), and if pg_upgrade fails, I report the failure and mention those
> files. If pg_upgrade succeeds, I remove the files? pg_upgrade already
> creates temporary files that it removes on completion.
OK, I have completed a rework of pg_upgrade logging. pg_upgrade had 4
logging options, -g, -G, -l, and -v, and still it wasn't possible to get
useful logging. :-(
What I have done with this patch is to remove -g, -G, and -l, and
unconditionally write to 4 log files in the current directory (in
addition to the 3 SQL files I already create).
If pg_upgrade succeeds, the files are removed, but if it fails (or if
the new -r/retain option is used), the files remain. Here is a sample
failure when I create a plpgsql function in the old server, but truncate
plpgsql.so in the new server:
Performing Upgrade
------------------
Analyzing all rows in the new cluster ok
Freezing all rows on the new cluster ok
Deleting new commit clogs ok
Copying old commit clogs 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
Consult the last few lines of "pg_upgrade_restore.log" for
the probable cause of the failure.
Failure, exiting
$ tail pg_upgrade_restore.log
COMMENT ON LANGUAGE plpythonu IS 'PL/PythonU untrusted procedural language';
COMMENT
SET search_path = public, pg_catalog;
SET
CREATE FUNCTION x() RETURNS integer
LANGUAGE plpgsql
AS $$begin
select pg_sleep(1);
end$$;
psql:/usr/local/pgdev/pg_upgrade/pg_upgrade_dump_db.sql:233:
ERROR: could not load library
"/usr/local/pgsql/lib/plpgsql.so":
/usr/local/pgsql/lib/plpgsql.so: file too short
That seems quite clear; I enabled --echo-queries in psql so you can see
the query that generated the error.
These changes should make pg_upgrade errors much easier to diagnose. I
hope to apply this for PG 9.2.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +