Jochem van Dieten <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> [ light dawns ] You've created a table named "text", haven't you?
> Yes, there is such a table. But even if I put the schema with
> that table in the search_path I can't reproduce the error from psql.
You can if you duplicate pg_
Tom Lane wrote:
I wrote:
[ light dawns ] You've created a table named "text", haven't you?
Yes, there is such a table. But even if I put the schema with
that table in the search_path I can't reproduce the error from psql.
You need this patch.
I prefer the interpretation "My customer n
I wrote:
> [ light dawns ] You've created a table named "text", haven't you?
You need this patch. Thanks for the report!
regards, tom lane
Index: pg_dump.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_du
Jochem van Dieten <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, that trace makes it look like it's unhappy about the "null::text"
>> in the command, because there is no other typecast in the SELECT target
>> statement.
> Problem database:
>> wedstrijdzeilen=> select * from pg_type where t
Tom Lane wrote:
Well, that trace makes it look like it's unhappy about the "null::text"
in the command, because there is no other typecast in the SELECT target
statement. Looking at the 7.3 code, the only very plausible reason for
the failure is if either "unknown" or "text" has disappeared fro
Jochem van Dieten <[EMAIL PROTECTED]> writes:
> (gdb) bt
> #0 0x16e73f in elog_message_prefix ()
> #1 0x16da26 in elog ()
> #2 0x82b3d in typecast_expression ()
> #3 0x818d9 in transformExpr ()
> #4 0x89d4d in transformTargetEntry ()
> #5 0x8a021 in transformTargetList ()
> #6 0x3cb78 in tra
Tom Lane wrote:
[ studies 7.3 code a bit ] It might work better to set the breakpoint at
elog_message_prefix, assuming you've got logging dialed down to the
point where only actual ERRORs go to the log.
Attaching to process 10284
0x403827df in ?? ()
(gdb) symbol-file postmaster
Reading symbol
Jochem van Dieten <[EMAIL PROTECTED]> writes:
> That's different from backtracing a core dump :) This better?
> Breakpoint 1, 0x16d8f8 in elog ()
> (gdb) bt
> #0 0x16d8f8 in elog ()
> #1 0x110abb in pg_exec_query_string ()
> #2 0x112a91 in PostgresMain ()
> #3 0xf4eae in DoBackend ()
> #4 0xf
Tom Lane wrote:
Jochem van Dieten <[EMAIL PROTECTED]> writes:
(gdb) break elog
Breakpoint 1 at 0x16d8f8
(gdb) bt
#0 0x403ca553 in ?? () from /usr/lib/libc.so.28.5
#1 0x10e604 in mdread ()
#2 0x10f31f in smgrread ()
You forgot to "continue" until the breakpoint is reached --- this trace
jus
Jochem van Dieten <[EMAIL PROTECTED]> writes:
> I get the following error:
>> C:\Program Files\PostgreSQL\8.0\bin>set PGOPTIONS="-W 30"
>>
>> "z:\backup\databases\2005-06-06\wedstrijdzeilen.sql"
>> WARNING: postgres: invalid command line arguments
Hm, that's odd ... but never mind, you thought
Tom Lane wrote:
Jochem van Dieten <[EMAIL PROTECTED]> 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
Yea
Jochem van Dieten <[EMAIL PROTECTED]> 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
I am experiencing a problem with dumping one specific database on
a cluster. All 143 other databases dump without giving errors.
The server runs PostgreSQL 7.3.2 on OpenBSD (I know :). pg_dump
is version 8.0.3 on Windows (upgraded from 8.0.1 which had the
same problem). The error message is:
13 matches
Mail list logo
