Re: Introduce pg_receivewal gzip compression tests
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: gkokolatos@pm.me
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andrew Dunstan <andrew@dunslane.net>
Date: 2021-07-16T05:08:57Z
Lists: pgsql-hackers
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
Commits
-
Re-enable TAP tests of pg_receivewal for ZLIB on Windows
- 91d395f47aa9 15.0 landed
-
Fix some issues with WAL segment opening for pg_receivewal --compress
- 11dbad74c104 10.18 landed
- 795a9166e2e1 11.13 landed
- b9a0de15eb29 12.8 landed
- fb2b86015a9f 13.4 landed
- 3a0d2d0cbaf3 14.0 landed
- 7fbe0c8c4d4f 15.0 landed
-
Disable tests involving ZLIB on Windows for pg_receivewal
- 6cea447e6a10 15.0 landed
-
Fix portability issue with gzip in TAP test of pg_receivewal
- 0da3c1bc3f72 15.0 landed
-
Add TAP tests for ZLIB compression for pg_receivewal
- ffc9ddaea33f 15.0 landed