At Mon, 26 Jul 2021 15:01:35 +0900, Michael Paquier <mich...@paquier.xyz> wrote in > On Sat, Jul 24, 2021 at 07:41:12PM +0900, Michael Paquier wrote: > > I have looked at that over the last couple of days, and applied it > > after some small fixes, including an indentation. > > One thing that we forgot here is the handling of trailing > whitespaces. Attached is small patch to adjust that, with one > positive and one negative tests. > > > The int64 and float > > parts are extra types we could handle, but I have not looked yet at > > how much benefits we'd get in those cases. > > I have looked at these two but there is really less benefits, so for > now I am not planning to do more in this area. For float options, > pg_basebackup --max-rate could be one target on top of the three set > of options in pgbench, but it needs to handle units :(
Thanks for revising and committing! I'm fine with all of the recent discussions on the committed part. Though I don't think it works for "live" command line options, making the omitting policy symmetric looks good. I see the same done in several similar use of strto[il]. The change in 020_pg_receivewal.pl results in a chain of four successive failures, which is fine. But the last failure (#23) happens for a bit dubious reason. > Use of uninitialized value in pattern match (m//) at t/020_pg_receivewal.pl > line 114. > not ok 23 - one partial WAL segment is now completed It might not be worth amending, but we don't need to use m/// there and eq works fine. 020_pg_receivewal.pl: 114 - is($zlib_wals[0] =~ m/$partial_wals[0]/, + is($zlib_wals[0] eq $partial_wals[0], regards. -- Kyotaro Horiguchi NTT Open Source Software Center