| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: pg_restore COPY error handling |
| Date: | 2006-02-01 23:03:41 |
| Message-ID: | 6274.1138835021@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Andrew Dunstan wrote:
>> I assume you are referring to this post:
>> http://archives.postgresql.org/pgsql-bugs/2006-01/msg00188.php
> OK, that helps. The solution is to "not do that", meaning install
> postgis before the restore or something. Anyway, adding the patch seems
> like too large a risk for a minor release, especially since you are the
> first person to complain about it that I remember.
I don't think you should see this as something specific to PostGIS.
If I interpret Stephen's report properly, any sort of failure during
COPY IN would lead to undesirable behavior in pg_restore.
This is not super surprising because the original design approach for
pg_restore was "bomb out on any sort of difficulty whatsoever". That
was justly complained about, and now it will try to keep going after
SQL-command errors ... but it sounds like the COPY-data processing
part didn't get fixed properly.
I take no position on whether Stephen's patch is any good --- I haven't
looked at it --- but if he's correct about the problem then I agree it's
a bug fix. Before deciding whether it deserves to be back-patched, we
at least ought to look closely enough to characterize the situations in
which pg_restore will fail.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2006-02-02 00:58:06 | Re: pg_restore COPY error handling |
| Previous Message | Bruce Momjian | 2006-02-01 22:53:23 | Re: pg_restore COPY error handling |