Robert Haas <rhaas@postgresql.org> writes:
> When VACUUM or ANALYZE skips a concurrently dropped table, log it.
When this went in, I was pretty skeptical of the value of an isolation
test for it, but said nothing. However, I now observe that the isolation
test is falling over on buildfarm machines with -DCLOBBER_CACHE_ALWAYS.
The buildfarm reports are a bit hard to interpret, but it's easy to
reproduce locally, and what I get is
$ more output_iso/regression.diffs
*** /home/postgres/pgsql/src/test/isolation/expected/vacuum-concurrent-drop.out
Mon Dec 4 17:02:55 2017
--- /home/postgres/pgsql/src/test/isolation/output_iso/results/vacuum-concurrent-drop.out Wed Dec 6 12:07:37
2017
***************
*** 49,54 ****
--- 49,55 ----
COMMIT;
step analyze_all: <... completed>
+ error in steps drop_and_commit analyze_all: ERROR: canceling statement due to user request
starting permutation: lock vac_analyze_specified drop_and_commit
step lock:
======================================================================
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.
regards, tom lane
