Lists: | pgsql-bugs |
---|
From: | Martin Gregorie <martin(at)gregorie(dot)org> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Problem with the pg_dumpall file format |
Date: | 2008-10-18 22:57:39 |
Message-ID: | 1224370660.3001.8.camel@zappa.gregorie.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
Guys,
I apologise for sending a bug report this way, but the bug reporting
server seems to be out to lunch at present. Firefox reports being able
to contact it but its bug submission wasn't accepted. To avoid loss of
the bug report, here it is:
Name: Martin Gregorie
e-mail: martin(at)gregorie(dot)org
Postgres: 8.2.10
OS: Linux (Fedora 9)
Details:
For some reason, when my message table (see below) is dumped, blank
lines are introduced between rows. Each row contains the contents of
each field. There isn't anything obvious in the final bytea field that
might cause this problem. There are longer rows than the
one preceding the blank line.
The blank lines cause the restore to crash with the message:
psql:cluster.sql:146200: ERROR: invalid input syntax for integer: ""
CONTEXT: COPY message, line 3, column sdbk: ""
The table definition is:
create table message
(
sdbk int primary key,
date_sent timestamp,
subject int
references subject(sdbk),
searchtext text,
headers bytea,
multipart boolean,
content bytea
);
If you need data samples, please ask.
Best regards,
Martin
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martin Gregorie <martin(at)gregorie(dot)org> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Problem with the pg_dumpall file format |
Date: | 2008-10-19 14:41:34 |
Message-ID: | 10721.1224427294@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
Martin Gregorie <martin(at)gregorie(dot)org> writes:
> For some reason, when my message table (see below) is dumped, blank
> lines are introduced between rows.
Nothing like that has been reported before. We have heard of dump files
getting corrupted after they've been produced --- the most common case
is newlines (\n) getting converted to carriage-return-line-feed (\r\n)
due to being copied onto a Windows machine. The COPY data format is
reasonably impervious to that, but I suppose it's possible that a second
conversion step might incorrectly change \r\n to \n\n.
If you're certain that nothing is happening to the dump file after the
fact, then we'll need to see a self-contained test case.
regards, tom lane