]> 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:42 +0000 (19:48 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 25 Jul 2014 23:48:42 +0000 (19:48 -0400)
commitc8e2e0e7129276440d1806dfe4f930c7177ccaac
tree4896cf67d25ebcde1c6e658281fc520a265ec812
parentde35a9771004b9d521c9d5882db6be4fba20e80e
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