]> granicus.if.org Git - postgresql/commit
Fix a performance problem in pg_dump's dump order selection logic.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 25 Jul 2014 23:48:45 +0000 (19:48 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 25 Jul 2014 23:48:45 +0000 (19:48 -0400)
commita8dddcaf758159059a83e147a960b369e9e3ab96
tree850c8735a2bc94f8c28a9842fbd71de5895b0ba2
parentdf58a17df29f7ec0ffc8389deee46e81a2a58a60
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.
src/bin/pg_dump/pg_dump_sort.c