Re: Why did commit 6271fceb8 enable debug logging for all TAP tests?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers@lists.postgresql.org
Date: 2018-05-07T02:46:02Z
Lists: pgsql-hackers
Attachments
- fix-redundant-regex-patterns.patch (text/x-diff) patch
Michael Paquier <michael@paquier.xyz> writes: > On Sun, May 06, 2018 at 09:49:46PM -0400, Tom Lane wrote: >> Now, that was neither mentioned in the commit message nor justified >> by any added test cases or scaffolding, so I'm assuming it was simply a >> mistake and should be reverted. Please confirm. > That was around to check that the debug messages generated when parsing > the backup_label file are correctly happening when running recovery > tests and made the patch validation handy. Let's remove it. Thanks for the info. The thing that led me to this was noticing that the src/bin/scripts/t/102_vacuumdb_stages.pl test case was taking a ridiculous amount of time: 24 seconds on my workstation, and several minutes on a slower test machine, all spent in the Perl script itself. After a bit of staring at the test case, I noticed that it was checking the expected server log output with a regex that had several occurrences of ".*.*". That makes the match formally underdetermined (i.e, you could divide the match between the first .* and the second .* arbitrarily). It's not really surprising that an NFA regex engine like Perl's might have exponentially bad behavior when trying to identify a match to such a pattern. But then I got confused again: that test pattern is the same for several releases back, but only HEAD is showing bad performance. Now the explanation is clear. Addition of DEBUG1 to the server configuration increases the amount of log text that needs to be matched against, and so the exponential match behavior crosses the threshold of being obvious. It's not increasing the amount of text all that much: on my machine, the postmaster log for this test case goes from 2914 bytes without DEBUG1 to 5382 bytes with it. I tried it at DEBUG5, and gave up after waiting about 15 minutes, by which time it had not finished the first and simpler of the two problematic regexes :-( The attached patch gets rid of the nonlinear match behavior by removing redundant occurrences of ".*". I think we should apply it not just to HEAD but to the relevant back branches, in case anyone tries to run this test with higher-than-default log levels. In the spirit of not breaking things right before a release, though, I'll hold off till after the wrap. regards, tom lane
Commits
-
Improve inefficient regexes in vacuumdb TAP test.
- da0b4c8a8add 10.5 landed
- c63913ca7d1d 11.0 landed
- 42e5a1b563da 9.5.14 landed
- 3d48654017aa 9.4.19 landed
- 36784e9147fa 9.6.10 landed
-
Undo extra chattiness of postmaster logs in TAP tests.
- 17551f1a21fa 11.0 landed
-
Add TIMELINE to backup_label file
- 6271fceb8a4f 11.0 cited