From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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:45:41 |
Message-ID: | 20060202024541.GQ4474@ns.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
* 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2006-02-02 02:53:54 | Re: pg_restore COPY error handling |
Previous Message | Andrew Dunstan | 2006-02-02 02:33:29 | Re: pg_restore COPY error handling |