Re: Warn when parallel restoring a custom dump without data offsets - Mailing list pgsql-hackers

From David Gilman
Subject Re: Warn when parallel restoring a custom dump without data offsets
Date
Msg-id 20200708031935.56el54wraqmd3fci@dar.local
Whole thread Raw
In response to Re: Warn when parallel restoring a custom dump without data offsets  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Warn when parallel restoring a custom dump without data offsets
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: Modifying data type of slot_keep_segs from XLogRecPtr to XLogSegNo
Next
From: Amit Kapila
Date:
Subject: Re: Default setting for enable_hashagg_disk (hash_mem)