Thread: pg_dumpall should permit quiet operation

pg_dumpall should permit quiet operation

From
"Neil T. Spring"
Date:
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

Re: [BUGS] pg_dumpall should permit quiet operation

From
Bruce Momjian
Date:
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

Re: [BUGS] pg_dumpall should permit quiet operation

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.

You seem to have missed the point completely - Neil wanted to suppress
the normal progress messages *on stderr* so that he'd only get an email
report when there was an abnormal event.  That request seemed fine to
me, though I thought the patch itself might have some portability
issues.  If it were recoded to follow the style of the existing boolean
options in pg_dumpall then I'd recommend accepting it.

            regards, tom lane

Re: [BUGS] pg_dumpall should permit quiet operation

From
Peter Eisentraut
Date:
Tom Lane writes:

> You seem to have missed the point completely - Neil wanted to suppress
> the normal progress messages *on stderr* so that he'd only get an email
> report when there was an abnormal event.  That request seemed fine to
> me, though I thought the patch itself might have some portability
> issues.  If it were recoded to follow the style of the existing boolean
> options in pg_dumpall then I'd recommend accepting it.

Two points:

1) The purpose of the progress messages is to inform the user of what
database he is connecting to.  Previously, the user just got a prompt
"Password:" and had to guess which one.  Unfortunately, it's hard for
pg_dumpall to predict whether a password prompt will appear.

This will become a nonissue soon because:

2) I'm currently rewriting pg_dumpall in C (as part of pg_dump actually),
so this patch will become obsolete.

(Also, I think we don't support external password files anymore, so the
password is now predictable and the progress messages can be removed, if
so.)

--
Peter Eisentraut   peter_e@gmx.net