Re: pg_restore: [custom archiver] dumping a specific TOC data block out of order is not supported without ID on this input stream (fseek required)

Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk> writes:
> The schema is fairly large, but I will try.

My guess is that you can reproduce it with not a lot of data, if you can
isolate the trigger condition.

> One thing I forgot to mention is that in the restore script I drop the indexes off my tables between restoring the schema and the data. I've always done this to speed up the restore, but is there any chance this could be causing the issue?

Possibly. I think there must be *something* unusual triggering the
problem, and maybe that is it or part of it.

> I guess what would help is some insight into what the error message means.

It's hard to tell. The likely theories are (1) we're doing things in an
order that requires seeking backwards in the file, and for some reason
pg_restore thinks it can't do that; (2) there's a bug causing the code
to search for a item number that isn't actually in the file.

One of the previous reports actually turned out to be pilot error: the
initial dump had failed after emitting a partially complete file, and
so the error from pg_restore was essentially an instance of (2). But
with three or so reports I'm thinking there's something else going on.

regards, tom lane