| From: | Stef <svb(at)ucs(dot)co(dot)za> |
|---|---|
| To: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: Bad dumps... |
| Date: | 2004-07-13 10:40:00 |
| Message-ID: | 20040713124000.49a556a0@svb.ucs.co.za |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
I found that it was actually a '\\N' value only that causes
dumps to dump successfully, but fail on import (When using COPY),
because both '\N' and '\\N' are seen as null by the COPY statement.
I just happened to have '\\N' values in my NOT NULL text field.
I now manually use this dump command :
pg_dump | sed 's:\\\\N:¬:g' | gzip > dump.gz
and do the reverse sed to restore.
Stef mentioned :
=> mike g mentioned :
=> => That could be a bug. How are you dumping the data? pg_dump? Select
=> => query? How are you restoring the data? psql?
=>
=> Dumping:
=> pg_dump -Ft | gzip > dump.tgz
=>
=> Restoring:
=> zcat dump.tgz | pg_restore -Ft |psql
=> OR
=> tar xvfz dump.tgz
=> perl -pi -e 's/\$\$PATH\$\$/$ENV{PWD}/g' restore.sql
=> psql -f restore.sql
=>
=> Both these methods, produce the same result.
=>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | evgeny tsurkin | 2004-07-13 11:32:47 | inheritance question |
| Previous Message | Simon Riggs | 2004-07-13 10:31:37 | Re: are there ways for 'idle timeout'? |