Re: pg_restore COPY error handling - Mailing list pgsql-patches

From Stephen Frost
Subject Re: pg_restore COPY error handling
Date
Msg-id 20060202024541.GQ4474@ns.snowman.net
Whole thread Raw
In response to Re: pg_restore COPY error handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_restore COPY error handling
Re: pg_restore COPY error handling
List pgsql-patches
* Tom Lane (tgl@sss.pgh.pa.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.

Alright, to do this, ExecuteSqlCommandBuf would need to be modified to
return an error-code other than 1 for when a command fails.  Thankfully,
only pg_backup_archiver.c uses ExecuteSqlCommandBuf, in ahwrite.
ahwrite would then need to return a value when there's an error (at the
moment it's defined to return int but everything appears to ignore its
return value).  We'd then need ahprintf to return a negative value when
it fails (at the moment it returns 'cnt' which appears to be the size of
what was written, except that nothing looks at the return value of
ahprintf either).

Once we have ahprintf returning a negative value when it fails, we can
modify pg_backup_archiver.c around line 332 to check if the ahprintf
failed for a COPY statement and if so to skip the:
(*AH->PrintTocDataPtr) (AH, te, ropt); // on line 335.

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. :/

    Thanks,

        Stephen

Attachment

pgsql-patches by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pg_restore COPY error handling
Next
From: Stephen Frost
Date:
Subject: Re: pg_restore COPY error handling