Thread: pg_dumpall fails

begin flood

bleh.  i can't tell if i'm getting somewhere, or running around in circles.
i don't know what my brother has been doing on the other end, but
pg_dumpall now returns this:

SELECT nextval ('"art_links_id_seq"');
dumpSequence(submissions_submission_id_seq): different sequence name
returned by SELECT: submissions_n_submission_id_seq
pg_dump failed on immedia2002, exiting


help?
--
=-=--------------------------------------------=-=
                       -.c.-

  My mistress when she walks treads on the ground.

Willy Wonka <lunchtime@onethirty.org> writes:
> i don't know what my brother has been doing on the other end, but
> pg_dumpall now returns this:

> SELECT nextval ('"art_links_id_seq"');
> dumpSequence(submissions_submission_id_seq): different sequence name
> returned by SELECT: submissions_n_submission_id_seq

What he's been doing is renaming sequences ... pg_dump doesn't like
that, for no particularly good reason :-(.  (This gratuitous failure
is gone in 7.3, but that doesn't help you much today.)  I'd suggest
dropping and recreating the sequence, then using setval() to set its
current value correctly.  Then you should be able to pg_dump.

            regards, tom lane

After a recent failure and restore I noticed two things that might be
bugs in pg_dumpall:

1. It saves the users passwords as plain text in the dump. (gack)
2. It doesnt seem to be i18n friendly.  Our tables had lots of
   umlats and accent's etc in them and they barfed on the restore
   noticed that they were represented as \0232 or such.  I had
   to hand fix all occurances to import.

--
Derek Neighbors
GNU Enterprise
http://www.gnuenterprise.org
derek@gnue.org

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=dneighbo

i'm getting further, i think.

i dropped and created the new sequence.  i don't think i had to set
the current value, because currval returned
submissions_submission_id_seq.currval is not yet defined in this
session [this database isn't on a production server at the moment]

now i get a new error:

>  pg_dumpall > bigdump
dumpSequence(website_suggest_id_seq): 0 (!= 1) tuples returned by SELECT
pg_dump failed on immedia2002, exiting

ok, so 0 isn't 1.  is there anything i can do about this one?

-c

At 11:38 PM -0400 9/27/02, Tom Lane wrote:
>Willy Wonka <lunchtime@onethirty.org> writes:
>>  i don't know what my brother has been doing on the other end, but
>>  pg_dumpall now returns this:
>
>  > SELECT nextval ('"art_links_id_seq"');
>  > dumpSequence(submissions_submission_id_seq): different sequence name
>>  returned by SELECT: submissions_n_submission_id_seq
>
>What he's been doing is renaming sequences ... pg_dump doesn't like
>that, for no particularly good reason :-(.  (This gratuitous failure
>is gone in 7.3, but that doesn't help you much today.)  I'd suggest
>dropping and recreating the sequence, then using setval() to set its
>current value correctly.  Then you should be able to pg_dump.
>
>            regards, tom lane

Derek Neighbors wrote:
-- Start of PGP signed section.
> After a recent failure and restore I noticed two things that might be
> bugs in pg_dumpall:
>
> 1. It saves the users passwords as plain text in the dump. (gack)

Use:

    password_encryption = true

and during the load the passwords will be MD5 encrypted.  However, this
disables pre-7.2 clients using crypt.  This will be the default in 7.3.


--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073