Horton

Re: Warn when parallel restoring a custom dump without data offsets

David Gilman <dgilman@gilslotd.com>

View thread View on postgr.es
From: David Gilman <dgilman@gilslotd.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, pryzby@telsasoft.com
Date: 2020-07-08T03:19:35Z
Lists: pgsql-hackers

Attachments

On Thu, Jul 02, 2020 at 05:25:21PM -0400, Tom Lane wrote:
> I guess I'm completely confused about the purpose of these patches.
> Far from coping with the situation of an unseekable file, they appear
> to change pg_restore so that it fails altogether if it can't seek
> its input file.  Why would we want to do this?

I'm not sure where the "fails altogether if it can't seek" is. The
"Skip tables in pg_restore" patch retains the old fread() logic. The
--disable-seeking stuff was just to support tests, and thanks to
help from Justin Pryzby the tests no longer require it. I've attached
the updated patch set.

Note that this still shouldn't be merged because of Justin's bug report
in 20200706050129.GW4107@telsasoft.com which is unrelated to this change
but will leave you with flaky CI until it's fixed.

-- 
David Gilman  :DG<
https://gilslotd.com

Commits

  1. Cope with data-offset-less archive files during out-of-order restores.

  2. Remove manual tracking of file position in pg_dump/pg_backup_custom.c.

  3. Improve performance of tuple conversion map generation

  4. Fix pg_restore so parallel restore doesn't fail when the input file doesn't