From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Greg Donald <gdonald(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: PostgreSQL 9.1 pg_dump setval() sets wrong value |
Date: | 2011-12-29 16:27:47 |
Message-ID: | CAHyXU0wjCAginZuys2NmpLMAuc1rjP7E=EkZjAfTAOc6v5pP-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Dec 29, 2011 at 10:20 AM, Greg Donald <gdonald(at)gmail(dot)com> wrote:
> On Wed, Dec 28, 2011 at 4:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> < SELECT pg_catalog.setval('cp_state_id_seq', 52, true);
>>> > SELECT pg_catalog.setval('cp_state_id_seq', 1, false);
>>
>> These "grep" calls are showing just exactly not enough to prove
>> anything.
>
> Those grep calls prove my old backups with 8.4 pg_dump were good to go
> and now they are not with 9.1 pg_dump.
>
>> I remain unclear as to what state is actually in the
>> database, or what is being dumped,
>
> The whole thing is being dumped. One command /usr/bin/pg_dump cp,
> that's it, nothing special.
if you take a bzipped schema only dump (pg_dump -s), I'd be happy to
look it over and eliminate the 'operator error' class of issues that
Tom is thinking might be happening. private mail is ok.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | David Salisbury | 2011-12-29 16:33:58 | Re: Refine Form of My querry |
Previous Message | Greg Donald | 2011-12-29 16:20:34 | Re: PostgreSQL 9.1 pg_dump setval() sets wrong value |