Re: BUG #5288: Restoring a 7.4.5 -Fc dump using -j 2 segfaults (patch included)

Jon Erdman <postgresql(at)thewickedtribe(dot)net> writes:
> Tom Lane wrote:
>> It seems like a good idea to put a range check into that loop as well,
>> but I think it should throw error not silently ignore bad data ...

> If things can be referenced that are not even in the dump, wouldn't it
> be somewhat likely that the dependency dumpId could be outside the range
> of Ids found in the TOC (and thus outside the range of the array,
> requiring a range check)?

Yeah, after looking at it further I concluded that you're right.
maxDumpId is only the highest dump ID actually found in the archive
--- I had been thinking it was transmitted by the originating pg_dump,
but it isn't. So we do need to guard against out-of-range dependency
IDs too; this code could fail on partial archives as well as old ones.

The partial archive case is a bit scary, because there might be indirect
dependencies we don't know about. It might be best to throw an error,
but for the moment I'll just make it ignore the dependency to the
missing object and we'll see if anyone complains.

> Mind if I take a crack at this patch?

I already did it before seeing your mail ...

regards, tom lane