Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table, log i

On Wed, Dec 6, 2017 at 4:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Well, I think it's a minute per query not per whole test script. But in
> any case, if it's taking a longer time than any other isolation test on
> the CLOBBER_CACHE_ALWAYS critters, then it's also taking a proportionately
> longer time than any other test on every other platform, and is therefore
> costing every developer precious time today and indefinitely far into the
> future. I continue to say that this test ain't worth it.

Sure. But, you also continue to not respond to my arguments about why
it IS worth it. I don't want to spend a lot of time fighting about
this, but it looks to me like your preferences here are purely
arbitrary. Yesterday, you added - without discussion - a test that I
had "obviously" left out by accident. Today, you want a test removed
that I added on purpose but which you assert has insufficient value.
So, sometimes you think it's worth adding tests that make the test
suite longer, and other times you think it isn't. That's fair enough
-- everyone comes down in different places on this at different times
-- but the only actual reason you've offered is that the script
contains a command that runs for over a minute on very slow machines
that have been artificially slowed down 100x. That's a silly reason:
it means that on real machines we're talking less than a second of
runtime even without modifying the test case, and if we do modify the
test, it can probably be made much less.

Please give me a little time to see if I can speed up this test enough
to fix this problem. If that doesn't work out, then we can rip this
out.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company