On Wed, May 05, 2021 at 01:41:03PM +0530, Dilip Kumar wrote: > I think we already have such test cases at least through pg_upgrade. > Basically, if you see in compression.sql we are not dropping the table > so that pg_upgrade and dump them and test. So if test run --with-lz4 > then in pg_upgrade dump we can see ALTER TABLE... SET COMPRESSION type > of commands.
The TAP tests of pg_dump are much more picky than what pg_upgrade is able to do. With the existing set of tests in place, what you are able to detect is that pg_upgrade does not *break* if there are tables with attributes using various compression types, but that would not be enough to make sure that the correct compression method is *applied* depending on the context expected (default_toast_compression + the attribute compression + pg_dump options), which is what the TAP tests of pg_dump are able to correctly detect if extended in an appropriate way. With what's on HEAD, we would easily miss any bugs introduced in pg_dump that change the set of commands generated depending on the options given by a user, but still allow pg_upgrade to work correctly. For example, there could be issues where we finish by setting up the incorrect compression option, with pg_upgrade happily finishing. There is a gap in the test coverage here. -- Michael
signature.asc
Description: PGP signature
