From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | File truncation within PostgresNode::issues_sql_like() wrong on Windows |
Date: | 2021-04-14 08:13:30 |
Message-ID: | YHajnhcMAI3++pJL@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
tap-sql-like-truncate.patch | text/x-diff | 1.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | osumi.takamichi@fujitsu.com | 2021-04-14 08:22:25 | RE: Truncate in synchronous logical replication failed |
Previous Message | Pavel Stehule | 2021-04-14 08:09:00 | Re: jsonb subscripting assignment performance |