File truncation within PostgresNode::issues_sql_like() wrong on Windows
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-14T08:13:30Z
Lists: pgsql-hackers
Attachments
- tap-sql-like-truncate.patch (text/x-diff) patch
Hi all, As fairywren has proved a couple of days ago, it is not really a good idea to rely on a file truncation to check for patterns in the logs of the backend: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2021-04-07%2013%3A29%3A28 Visibly, a logic based on the log file truncation fails on Windows because of the concurrent access of the backend that outputs its logs there. In PostgresNode.pm, connect_ok() and connect_access() enforce a rotation of the log file before restarting the server on Windows to make sure that a given step does not find logs generated by a previous test, but that's not the case of issues_sql_like(). Looking at the existing tests using this routine (src/bin/scripts/), I have found on test in 090_reindexdb.pl that could lead to a false positive. The test is marked in the patch attached, just for awareness. Would there be any objections to change this routine so as we avoid the file truncation on Windows? The patch attached achieves that. Any thoughts? -- Michael
Commits
-
Replace magic constants for seek() calls in perl scripts
- c731f9187b5f 14.0 landed
-
Allow TestLib::slurp_file to skip contents, and use as needed
- d48212c45202 9.6.22 landed
- f8ba416a98ce 10.17 landed
- 4c9298130ae8 11.12 landed
- d380ec9891db 12.7 landed
- e480c6dd33f4 13.3 landed
- 3c5b0685b921 14.0 landed