Re: pg_dumpall should permit quiet operation - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: pg_dumpall should permit quiet operation
Date
Msg-id 200206202348.g5KNmOn04432@candle.pha.pa.us
Whole thread Raw
In response to pg_dumpall should permit quiet operation  ("Neil T. Spring" <nspring@cs.washington.edu>)
Responses Re: [PATCHES] pg_dumpall should permit quiet operation
List pgsql-bugs
Without showing the database being dumped, the entire output of
pg_dumpall seems pretty useless so you may as well pipe the whole output
to /dev/null.  I don't think a quiet feature for pg_dumpall has enough
use for ordinary users. Sorry.

---------------------------------------------------------------------------

Neil T. Spring wrote:
> pg_dumpall now prints status messages;  I find them to be a
> nuisance, and the patch below implements a --quiet option,
> though not necessarily well.
>
> thanks,
> -neil
>
> ============================================================================
>                         POSTGRESQL BUG REPORT TEMPLATE
> ============================================================================
>
>
> Your name        :     Neil Spring
> Your email address    : nspring@cs.washington.edu
>
>
> System Configuration
> ---------------------
>   Architecture (example: Intel Pentium)      : PIII dual 1GHz
>
>   Operating System (example: Linux 2.0.26 ELF)     : Debian Woody / 2.4.18
>
>   PostgreSQL version (example: PostgreSQL-7.2.1):   PostgreSQL-7.2.1
>
>   Compiler used (example:  gcc 2.95.2)        :  2.95.4
>
>
> Please enter a FULL description of your problem:
> ------------------------------------------------
>
> pg_dumpall now prints status messages to stderr, which makes
> it less suitable for a nightly cron job to backup the
> database.   I either get nightly useless mail, or redirect
> stderr so that I don't know about errors.  pg_dumpall
> should not print those messages, or at least support
> a --quiet option.
>
>
> Please describe a way to repeat the problem.   Please try to provide a
> concise reproducible example, if at all possible:
> ----------------------------------------------------------------------
>
> type "pg_dumpall > x". watch informational messages appear.
>
>
>
> If you know how this problem might be fixed, list the solution below:
> ---------------------------------------------------------------------
>
> patch to pg_dumpall.sh follows.   A patch to pg_dumpall.1 is
> straightforward, assuming this is the way to deal with the problem.
>
> diff -cr postgresql-7.2.1/src/bin/pg_dump/pg_dumpall.sh postgresql/src/bin/pg_dump/pg_dumpall.sh
> *** postgresql-7.2.1/src/bin/pg_dump/pg_dumpall.sh    Sun Feb 10 16:18:20 2002
> --- postgresql/src/bin/pg_dump/pg_dumpall.sh    Tue Apr 23 14:22:56 2002
> ***************
> *** 87,92 ****
> --- 87,96 ----
>                   echo "pg_dumpall (PostgreSQL) $VERSION"
>                   exit 0
>                   ;;
> +         --quiet|-q)
> +             quiet=t
> +             break
> +             ;;
>       --host|-h)
>           connectopts="$connectopts -h $2"
>           shift;;
> ***************
> *** 144,149 ****
> --- 148,154 ----
>       echo "  -g, --globals-only     Only dump global objects, no databases"
>       echo "  -h, --host=HOSTNAME    Server host name"
>       echo "  -p, --port=PORT        Server port number"
> +     echo "  -q, --quiet            Don't print status messages to stderr"
>       echo "  -U, --username=NAME    Connect as specified database user"
>       echo "  -W, --password         Force password prompts (should happen automatically)"
>       echo "Any extra options will be passed to pg_dump.  The dump will be written"
> ***************
> *** 169,175 ****
>   echo "DELETE FROM pg_shadow WHERE usesysid <> (SELECT datdba FROM pg_database WHERE datname = 'template0');"
>   echo
>
> ! echo "connected to template1..." 1>&2
>   $PSQL -d template1 -At -c "\
>   SELECT
>     'CREATE USER \"' || usename || '\" WITH SYSID ' || usesysid
> --- 174,180 ----
>   echo "DELETE FROM pg_shadow WHERE usesysid <> (SELECT datdba FROM pg_database WHERE datname = 'template0');"
>   echo
>
> ! [ "$quiet" ] || echo "connected to template1..." 1>&2
>   $PSQL -d template1 -At -c "\
>   SELECT
>     'CREATE USER \"' || usename || '\" WITH SYSID ' || usesysid
> ***************
> *** 235,241 ****
>       fi
>
>       echo "${BS}connect \"$DATABASE\" \"$DBOWNER\""
> !     echo "dumping database \"$DATABASE\"..." 1>&2
>       $PGDUMP "$DATABASE" <&4
>       if [ "$?" -ne 0 ] ; then
>           echo "pg_dump failed on $DATABASE, exiting" 1>&2
> --- 240,246 ----
>       fi
>
>       echo "${BS}connect \"$DATABASE\" \"$DBOWNER\""
> !     [ "$quiet" ] || echo "dumping database \"$DATABASE\"..." 1>&2
>       $PGDUMP "$DATABASE" <&4
>       if [ "$?" -ne 0 ] ; then
>           echo "pg_dump failed on $DATABASE, exiting" 1>&2
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch for memory leaks in index scan
Next
From: Bruce Momjian
Date:
Subject: Re: Patch for memory leaks in index scan