Re: pg_restore COPY error handling

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: pg_restore COPY error handling
Date: 2006-02-02 02:53:54
Message-ID: 20060202025354.GR4474@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

* Stephen Frost (sfrost(at)snowman(dot)net) wrote:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > ISTM you should be depending on the archive structure: at some level,
> > at least, pg_restore knows darn well whether it is dealing with table
> > data or SQL commands.
>
[...]
> I'd be happy to work this up, and I think it would work, but it seems
> kind of ugly since then we'd have ahwrite and ahprintf returning error
> codes which in 99% of the cases wouldn't be checked which doesn't seem
> terribly clean. :/

Looking at this again, I'm not 100% sure it'd work quite that cleanly.
I'm not sure you can just skip that PrintTocDataPtr call, depending on
the how the input is coming in... There might be a way to modify
_PrintData (in pg_backup_custom.c, and the others, which is what is
the function behind PrintTocDataPtr) to somehow check an AH variable
which essentially says "the data command failed, just ignore the input",
and we'd need to set the AH variable somewhere else, perhaps using the
return value setup I described before...

All of this is sounding rather invasive though. I have to admit that
I'm not exactly a big fan of the pg_dump/pg_restore modular system. :/

Thanks,

Stephen

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-02-02 02:54:51 Re: pg_restore COPY error handling
Previous Message Stephen Frost 2006-02-02 02:45:41 Re: pg_restore COPY error handling