On Wed, Apr 05, 2017 at 11:13:33AM -0400, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost <sfr...@snowman.net> writes: > > > I'm all for adding tests into pg_dump which do things like drop columns > > > and change column names and other cases which could impact if the > > > pg_dump is correct or not, and there's nothing preventing those tests > > > from being added in the existing structure. Certainly, before we remove > > > the coverage provided by running the serial test suite and then using > > > pg_upgrade, we should analyze what is being tested and ensure that we're > > > providing that same set of testing in the pg_dump TAP tests. > > > > I don't think you grasped my basic point, which is that I'm worried about > > emergent cases that we don't foresee needing to test (and that no amount > > of code coverage checking would have shown up as being overlooked). > > Admittedly, relying on the core regression tests to trigger such cases is > > a pretty haphazard strategy, but it's way better than no strategy at all. > > The tests that were added to the core regression suite were done so for > a reason and hopefully we can identify cases where it'd make sense to > also run those tests for pg_upgrade/pg_dump testing.
I think you _are_ missing Tom's point. We've caught pg_dump and pg_upgrade bugs thanks to regression database objects created for purposes unrelated to pg_dump. It's true that there exist other test strategies that are more efficient or catch more bugs overall. None of them substitute 100% for the serendipity seen in testing dump/restore on the regression database. > More-or-less > anything that materially changes the catalog should be included, I would > think. Things that are only really only working with the heap/index > files don't really need to be performed because the pg_upgrade process > doesn't change those. That is formally true. Also, I agree with Andres that this is not a thread for discussing test changes beyond mechanical translation of the pg_upgrade test suite. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers