From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jochem van Dieten <jochemd(at)oli(dot)tudelft(dot)nl> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_dump 8.0.3 failing against PostgreSQL 7.3.2 |
Date: | 2005-06-06 14:56:15 |
Message-ID: | 26091.1118069775@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jochem van Dieten <jochemd(at)oli(dot)tudelft(dot)nl> writes:
> Below I have copy pasted the console log which has some
> additional information. This bug, or a related one, seems to have
> been registered previously as bug #1455
> http://archives.postgresql.org/pgsql-bugs/2005-02/msg00021.php
Yeah. We never heard back from that person, so I thought he'd resolved
his problem, but maybe there's something in common.
It's *really* odd that you can do the same command by hand and it
doesn't fail. Just to get the Windows version out of the loop:
if you run 7.3's own pg_dump directly on the BSD box, does it fail
the same way?
The only way I can think of to get more info is to try to get a
stack trace for the error --- that is, attach to the backend process
with gdb, set a breakpoint at elog, let it run till the error occurs,
and then "bt" to see how control got to the failure. Can you do that?
It will help if you do something like
export PGOPTIONS="-W 30"
on the client side before starting pg_dump --- that will provide a
30-second delay during connection to give you time to identify the
connected backend and attach to it with gdb.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Franco Bruno Borghesi | 2005-06-06 15:02:19 | Re: return two elements |
Previous Message | Rodríguez Rodríguez, Pere | 2005-06-06 14:45:54 | return two elements |