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>
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

In response to

Responses

Browse pgsql-patches by date

  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