From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Unified logging system for command-line programs |
Date: | 2019-04-09 11:58:14 |
Message-ID: | 20190409115814.GB1961@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Re: Peter Eisentraut 2019-04-01 <E1hB1d6-00051m-1s(at)gemulon(dot)postgresql(dot)org>
> - There is support for setting a "log level". This is not meant to be
> user-facing, but can be used internally to implement debug or
> verbose modes.
I'm not entirely sure what happened here, but I think this made
pg_restore verbose by default (and there is no --quiet option).
At least that's what the apt.pg.o upgrade regression tests say for
11->12:
09:12:49 ok 59 - pg_upgradecluster reported successful operation
09:12:49 not ok 60 - no error messages during upgrade
09:12:49 # Failed test 'no error messages during upgrade'
09:12:49 # at ./t/040_upgrade.t line 160.
09:12:49 pg_restore: connecting to database for restore
09:12:49 pg_restore: executing BLOB 1234
09:12:49 pg_restore: disabling triggers for tstab
09:12:49 pg_restore: processing data for table "public.tstab"
09:12:49 pg_restore: enabling triggers for tstab
09:12:49 pg_restore: processing BLOBS
09:12:49 pg_restore: restoring large object with OID 1234
09:12:49 pg_restore: restored 1 large object
09:12:49 pg_restore: connecting to database for restore
09:12:49 pg_restore: connecting to database for restore
09:12:49 pg_restore: disabling triggers for nums
09:12:49 pg_restore: processing data for table "public.nums"
09:12:49 pg_restore: enabling triggers for nums
09:12:49 pg_restore: connecting to database for restore
09:12:49 pg_restore: connecting to database for restore
09:12:49 pg_restore: disabling triggers for old
09:12:49 pg_restore: processing data for table "old.old"
09:12:49 pg_restore: enabling triggers for old
09:12:49 pg_restore: disabling triggers for phone
09:12:49 pg_restore: processing data for table "public.phone"
09:12:49 pg_restore: enabling triggers for phone
09:12:49 pg_restore: executing SEQUENCE SET odd10ok 61 - pg_lsclusters -h
09:12:49 ok 62 - pg_lsclusters output
The code running there is:
print 'Upgrading database ', $db, "...\n";
open SOURCE, '-|', $pg_dump, '-h', $oldsocket, '-p', $info{'port'},
'-Fc', '--quote-all-identifiers', $db or
error 'Could not execute pg_dump for old cluster';
# start pg_restore and copy over everything
my @restore_argv = ($pg_restore, '-h', $newsocket, '-p',
$newinfo{'port'}, '--data-only', '-d', $db,
'--disable-triggers', '--no-data-for-failed-tables');
open SINK, '|-', @restore_argv or
error 'Could not execute pg_restore for new cluster';
https://salsa.debian.org/postgresql/postgresql-common/blob/master/pg_upgradecluster#L511-521
Christoph
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2019-04-09 12:01:12 | Re: PGCOLOR? (Re: pgsql: Unified logging system for command-line programs) |
Previous Message | Peter Eisentraut | 2019-04-09 10:55:22 | Re: PGCOLOR? (Re: pgsql: Unified logging system for command-line programs) |
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2019-04-09 12:01:12 | Re: PGCOLOR? (Re: pgsql: Unified logging system for command-line programs) |
Previous Message | Ibrar Ahmed | 2019-04-09 11:52:02 | Re: dropdb --force |