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
Justin Pryzby 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 w
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,
