I started fooling with this at home while our ISP is broke (pardon my brevity).
Maybe you also saw commit b779ea8a9a2dc3a089b3ac152b1ec4568bfeb26f "Fix pg_restore so parallel restore doesn't fail when the input file doesn't contain data offsets (which it won't, if pg_dump thought its output wasn't seekable)..." ...which I guess should actually say "doesn't NECESSARILY fail", since it also adds this comment: "This could fail if we are asked to restore items out-of-order." So this is a known issue and not a regression. I think the PG11 commit you mentioned (548e5097) happens to make some databases fail in parallel restore that previously worked (I didn't check). Possibly also some databases (or some pre-existing dumps) which used to fail might possibly now succeed. Your patch adds a warning if unseekable output might fail during parallel restore. I'm not opposed to that, but can we just make pg_restore work in that case? If the input is unseekable, then we can never do a parallel restore at all. If it *is* seekable, could we make _PrintTocData rewind if it gets to EOF using ftello(SEEK_SET, 0) and re-scan again from the beginning? Would you want to try that ?
