On Wed, May 5, 2021 at 4:00 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> 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.
Okay, got your point.
> 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.
Basically, the problem is default compilation is --without-lz4 so by
default there is only one compression method and with only one
compression method we can not generate the test case you asked for,
because that will be the default compression method and we don't dump
the default compression method.
So basically, if we have to write this test case in pg_dump then we
will have to use lz4 which means it will generate different output
--with-lz4 vs --without-lz4. With a simple regress test it easy to
deal with such cases by keeping multiple .out files but I am not sure
can we do this easily with pg_dump test without adding much
complexity?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
