Horton

Thread

Commits

  1. In pg_restore's dump_lo_buf(), work a little harder on error handling.

  2. Enable large file support.

  1. pg_restore error message during ENOSPC with largeobj

    Justin Pryzby <pryzby@telsasoft.com> — 2020-10-18T01:02:32Z

    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

  2. Re: pg_restore error message during ENOSPC with largeobj

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-10-18T02:41:43Z

    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

  3. Re: pg_restore error message during ENOSPC with largeobj

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-10-18T16:27:36Z

    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