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