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

2017-12-07 Thread Robert Haas
On Wed, Dec 6, 2017 at 9:42 PM, Bossart, Nathan wrote: > On 12/6/17, 8:25 PM, "Robert Haas" wrote: >> 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. > > Just in case it got missed earlier, here

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

2017-12-06 Thread Robert Haas
On Wed, Dec 6, 2017 at 4:31 PM, Tom Lane 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 o

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

2017-12-06 Thread Tom Lane
Robert Haas writes: > On Wed, Dec 6, 2017 at 12:57 PM, Tom Lane 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. > Is it really our policy that no

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

2017-12-06 Thread Robert Haas
On Wed, Dec 6, 2017 at 12:57 PM, Tom Lane 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 th