pg_restore error message during ENOSPC with largeobj
I overflowed my homedir while testing with pg_reload, and got:
|pg_restore: error: could not write to large object (result: 18446744073709551615, expected: 30)
src/bin/pg_dump/pg_backup_archiver.c
f (res != AH->lo_buf_used)
fatal("could not write to large object (result: %lu, expected: %lu)",
(unsigned long) res, (unsigned long) AH->lo_buf_used);
; 18446744073709551615 - 1<<64
-1
I guess casting to long was the best option c. 2002 (commit 6faf8024f) but I
gather the modern way is with %z.
I confirmed this fixes the message.
|pg_restore: error: could not write to large object (result: -1, expected: 16384)
--
Justin
Attachments:
v1-0001-print-size_t-with-zd-rather-than-casting-to-lu.patchtext/x-diff; charset=us-asciiDownload+12-13
Justin Pryzby <pryzby@telsasoft.com> writes:
I overflowed my homedir while testing with pg_reload, and got:
|pg_restore: error: could not write to large object (result: 18446744073709551615, expected: 30)
Bleah.
I guess casting to long was the best option c. 2002 (commit 6faf8024f) but I
gather the modern way is with %z.
Isn't the real problem that lo_write returns int, not size_t?
AFAICT, every other call site stores the result in an int,
it's just this one that's out in left field.
regards, tom lane
I wrote:
Isn't the real problem that lo_write returns int, not size_t?
After looking at it some more, I decided that we'd just been lazy
to begin with: we should be handling this as a regular SQL error
condition. Pushed at 929c69aa19.
regards, tom lane