Skip to content

Commit 929c69a

Browse files
committed
In pg_restore's dump_lo_buf(), work a little harder on error handling.
Failure to write data to a large object during restore led to an ugly and uninformative error message. To add insult to injury, it then fatal'd out, where other SQL-level errors usually result in pressing on. Report the underlying error condition, rather than just giving not-very- useful byte counts, and use warn_or_exit_horribly() so as to adhere to pg_restore's general policy about whether to continue or not. Also recognize that lo_write() returns int not size_t. Per report from Justin Pryzby, though I didn't use his patch. Given the lack of comparable complaints, I'm not sure this is worth back-patching. Discussion: https://postgr.es/m/20201018010232.GF9241@telsasoft.com
1 parent 7d00a6b commit 929c69a

File tree

1 file changed

+7
-6
lines changed

1 file changed

+7
-6
lines changed

src/bin/pg_dump/pg_backup_archiver.c

Lines changed: 7 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1637,16 +1637,17 @@ dump_lo_buf(ArchiveHandle *AH)
16371637
{
16381638
if (AH->connection)
16391639
{
1640-
size_t res;
1640+
int res;
16411641

16421642
res = lo_write(AH->connection, AH->loFd, AH->lo_buf, AH->lo_buf_used);
1643-
pg_log_debug(ngettext("wrote %lu byte of large object data (result = %lu)",
1644-
"wrote %lu bytes of large object data (result = %lu)",
1643+
pg_log_debug(ngettext("wrote %zu byte of large object data (result = %d)",
1644+
"wrote %zu bytes of large object data (result = %d)",
16451645
AH->lo_buf_used),
1646-
(unsigned long) AH->lo_buf_used, (unsigned long) res);
1646+
AH->lo_buf_used, res);
1647+
/* We assume there are no short writes, only errors */
16471648
if (res != AH->lo_buf_used)
1648-
fatal("could not write to large object (result: %lu, expected: %lu)",
1649-
(unsigned long) res, (unsigned long) AH->lo_buf_used);
1649+
warn_or_exit_horribly(AH, "could not write to large object: %s",
1650+
PQerrorMessage(AH->connection));
16501651
}
16511652
else
16521653
{

0 commit comments

Comments
 (0)