On Fri, Jul 16, 2021 at 08:59:11AM +0900, Michael Paquier wrote: > --compress is used and the sync fails for a non-compressed segment. > Looking at the code it is pretty obvious that open_walfile() is > getting confused with the handling of an existing .partial segment > while walmethods.c uses dir_data->compression in all the places that > matter. So that's a legit bug, that happens only when mixing > pg_receivewal runs for where successive runs use the compression or > non-compression modes.
Ditto. After reading the code more carefully, the code is actually able to work even if it could be cleaner: 1) dir_existsfile() would check for the existence of a non-compressed, partial segment all the time. 2) If this non-compressed file was padded, the code would use open_for_write() that would open a compressed, partial segment. 3) The compressed, partial segment would be the one flushed. This behavior is rather debatable, and it would be more instinctive to me to just skip any business related to the pre-padding if compression is enabled, at the cost of one extra callback in WalWriteMethod to grab the compression level (dir_open_for_write() skips that for compression) to allow receivelog.c to handle that. But at the same time few users are going to care about that as pg_receivewal has most likely always the same set of options, so complicating this code is not really appealing either. > I am amazed that the other buildfarm members are not complaining, to > be honest. jacana runs this TAP test with MinGW and ZLIB, and does > not complain. I have spent more time on that with my own environment, and while testing I have bumped on a different issue with zlib, which was really weird. In the same scenario as above, gzdopen() has been failing for me at step 2), causing the test to loop forever. We document to use DLLs for ZLIB coming from zlib.net, but the ones available there are really outdated as far as I can see (found some called zlib.lib/dll myself, breaking Solution.pm). For now I have disabled those tests on Windows to bring back bowerbird to green, but there is something else going on here. We don't do much tests with ZLIB on Windows for pg_basebackup and pg_dump, so there may be some more issues? @Andrew: which version of ZLIB are you using on bowerbird? That's the one in c:\prog\3p64. That's a zdll.lib, right? -- Michael
signature.asc
Description: PGP signature
