Re: pg_upgrade --logfile option documentation

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. +