aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-10-18 12:26:02 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-10-18 12:26:02 -0400
commit929c69aa1970b3ae30bbb5a159b9dc530ec34d5c (patch)
tree50d7c3c38cf8105c16ac7f9cc4d17f7739603e6e /src/backend/executor/nodeModifyTable.c
parent7d00a6b2de8ab1e95e052663064defb0bc3022f6 (diff)
downloadpostgresql-929c69aa1970b3ae30bbb5a159b9dc530ec34d5c.tar.gz
postgresql-929c69aa1970b3ae30bbb5a159b9dc530ec34d5c.zip
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
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions