Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

2021-04-18 Thread Michael Paquier
On Sat, Apr 17, 2021 at 09:55:47AM -0400, Andrew Dunstan wrote: > Yes please, much better to use a symbolic name rather than a magic > number. I wouldn't bother backpatching it though. Okay, done this way then. -- Michael signature.asc Description: PGP signature

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

2021-04-17 Thread Andrew Dunstan
On 4/17/21 9:04 AM, Michael Paquier wrote: > On Thu, Apr 15, 2021 at 09:12:52PM -0400, Andrew Dunstan wrote: >> It's worked on fairywren, I will double check on drongo and if all is >> well will commit. > Thanks Andrew. For the archive's sake, this has been committed as of > 3c5b068. > > While r

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

2021-04-17 Thread Michael Paquier
On Thu, Apr 15, 2021 at 09:12:52PM -0400, Andrew Dunstan wrote: > It's worked on fairywren, I will double check on drongo and if all is > well will commit. Thanks Andrew. For the archive's sake, this has been committed as of 3c5b068. While reading the commit, I have noticed that you used SEEK_SE

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

2021-04-15 Thread Andrew Dunstan
On 4/15/21 8:36 PM, Michael Paquier wrote: > On Thu, Apr 15, 2021 at 07:16:05AM -0400, Andrew Dunstan wrote: >> Reviewing the history, I don't want to undo 114541d58e5. > Maybe we could remove it, but that may be better as a separate > discussion if it is proving to not improve the situation, and

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

2021-04-15 Thread Michael Paquier
On Thu, Apr 15, 2021 at 07:16:05AM -0400, Andrew Dunstan wrote: > Reviewing the history, I don't want to undo 114541d58e5. Maybe we could remove it, but that may be better as a separate discussion if it is proving to not improve the situation, and I don't really want to take any risks in destabil

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

2021-04-15 Thread Andrew Dunstan
On 4/15/21 12:57 AM, Michael Paquier wrote: > On Wed, Apr 14, 2021 at 09:26:19PM -0400, Andrew Dunstan wrote: >> Well, let me try it on fairywren tomorrow. Since we manage this on the >> buildfarm without any use at all of Win32API::File it might not be >> necessary in TAP code either, particular

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

2021-04-14 Thread Michael Paquier
On Wed, Apr 14, 2021 at 09:26:19PM -0400, Andrew Dunstan wrote: > Well, let me try it on fairywren tomorrow. Since we manage this on the > buildfarm without any use at all of Win32API::File it might not be > necessary in TAP code either, particularly if we're not truncating the file. Thanks. If t

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

2021-04-14 Thread Andrew Dunstan
On 4/14/21 8:10 PM, Michael Paquier wrote: > On Wed, Apr 14, 2021 at 05:10:41PM -0400, Andrew Dunstan wrote: >> That seems rather heavy-handed. The buildfarm's approach is a bit >> different. Essentially it seeks to the previous position of the log file >> before reading contents. Here is its equ

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

2021-04-14 Thread Michael Paquier
On Wed, Apr 14, 2021 at 05:10:41PM -0400, Andrew Dunstan wrote: > That seems rather heavy-handed. The buildfarm's approach is a bit > different. Essentially it seeks to the previous position of the log file > before reading contents. Here is its equivalent of slurp_file: > > use Fcntl qw(:seek

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

2021-04-14 Thread Andrew Dunstan
On 4/14/21 4:13 AM, Michael Paquier wrote: > 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%