Fix a performance problem in pg_dump's dump order selection logic.
findDependencyLoops() was not bright about cases where there are multiple
dependency paths between the same two dumpable objects. In most scenarios
this did not hurt us too badly; but since the introduction of section
boundary pseudo-objects in commit a1ef01fe163b304760088e3e30eb22036910a495,
it was possible for this code to take unreasonable amounts of time (tens
of seconds on a database with a couple thousand objects), as reported in
bug #11033 from Joe Van Dyk. Joe's particular problem scenario involved
"pg_dump -a" mode with long chains of foreign key constraints, but I think
that similar problems could arise with other situations as long as there
were enough objects. To fix, add a flag array that lets us notice when we
arrive at the same object again while searching from a given start object.
This simple change seems to be enough to eliminate the performance problem.
Back-patch to 9.1, like the patch that introduced section boundary objects.
Branch
------
REL9_4_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/a8dddcaf758159059a83e147a960b369e9e3ab96
Modified Files
--------------
src/bin/pg_dump/pg_dump_sort.c | 54 +++++++++++++++++++++++++++++++++-------
1 file changed, 45 insertions(+), 9 deletions(-)
