Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > I believe that what Peter was getting at is that the pg_dump TAP tests > > create a whole slew of objects in just a few seconds and are able to > > then exercise those code-paths in pg_dump, without needing to run the > > entire serial regression test run. > > Right. But there's a certain amount of serendipity involved in using the > core regression tests' final results. For example, I don't know how long > it would've taken us to understand the problems around dumping and > reloading child tables with inconsistent column orders, had there not been > examples of that in the regression tests. I worry that creating a sterile > set of objects for testing pg_dump will leave blind spots, because it will > mean that we only test cases that we explicitly created test cases for.
We don't need to only create sterile sets of objects in the pg_dump TAP tests. I don't believe we need to populate GIN indexes or vacuum them to test pg_dump/pg_upgrade either (at least, not if we're going to stick to the pg_upgrade test basically being if pg_dump returns the same results before-and-after). 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'm still not completely convinced that we actually need to > > independently test pg_upgrade by creating all the objects which the > > pg_dump TAP tests do, given that pg_upgrade just runs pg_dump > > underneath. If we really want to do that, however, what we should do is > > abstract out the pg_dump set of tests into a place that both the pg_dump > > and pg_upgrade TAP tests could use them to create all the types of > > objects which are supported to perform their tests. > > I think it's largely pointless to test pg_dump --binary-upgrade except > as a part of pg_upgrade. That's how I discovered that comments and security labels weren't being pulled through to the new cluster for blobs, so I would have to disagree with this. Frankly, it's also much more straight-forward to run pg_dump --binary-upgrade than it is to get pg_upgrade to do the same. Still, I'm not actually against centralizing the tests done with pg_dump such that they could be used by pg_upgrade also. Creating all those objects takes less than a second, at least on my system, so it would still be quite a bit faster than running the serial regression suite. We might also consider if there's a way to change the format for those tests to make them a bit less impenetrable for non-Perl folks to work with and to make it simpler to add new tests as new features are added. Thanks! Stephen
signature.asc
Description: Digital signature
