On Wed, Dec 6, 2017 at 12:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > What appears to be happening is that a database-wide ANALYZE takes more > than a minute under CLOBBER_CACHE_ALWAYS, causing isolationtester.c's > hardwired one-minute timeout to trigger. > > While you could imagine doing something to get around that, I do not > believe that this test is worth memorializing in perpetuity to begin > with. I'd recommend just taking it out again.
Mumble. I don't really mind that, but I'll bet $0.05 that this will get broken at some point and we won't notice right away without the isolation test. Is it really our policy that no isolation test can take more than a minute on the slowest buildfarm critter? If somebody decides to start running CLOBBER_CACHE_ALWAYS on an even-slower critter, will we just nuke isolation tests from orbit until the tests pass there? I have difficulty seeing that as a sound approach. Another thought is that it might not be necessary to have a database-wide ANALYZE to trigger this. I managed to reproduce it locally by doing VACUUM a, b while alternately locking a and b, so that I let the name lookups complete, but then blocked trying to vacuum a, and then at that point dropped b, then released the VACUUM. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
