Обсуждение: strange isolation test buildfarm failure on guaibasaurus
Hi all! http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2012-12-05%2016%3A17%3A01 seems like a rather odd failure in the isolation test (client) Stefan
Stefan Kaltenbrunner wrote: > Subject: [HACKERS] strange isolation test buildfarm failure on guaibasaurus > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2012-12-05%2016%3A17%3A01 > seems like a rather odd failure in the isolation test (client) Lines which might get the attention of interested parties: (using postmaster on Unix socket, default port) ============== dropping database "isolationtest" ============== NOTICE: database "isolationtest" does not exist, skipping DROP DATABASE ============== creating database "isolationtest" ============== CREATE DATABASE ALTER DATABASE ============== running regression test queries ============== test simple-write-skew ... ok test receipt-report ... ok test temporal-range-integrity ... ok test project-manager ... ok test classroom-scheduling ... ok test total-cash ... ok test referential-integrity ... ok test ri-trigger ... ok test partial-index ... ok test two-ids ... ok test multiple-row-versions ... ok test index-only-scan ... ok test fk-contention ... ok test fk-deadlock ... ok test fk-deadlock2 ... ok test eval-plan-qual ... ok test drop-index-concurrently-1 ... FAILED (test process exited with exit code 1) =======================1 of 17 tests failed. ======================= The differences that caused some tests to fail can be viewed in the file "/home/pgsql/buildfarm/buildroot/HEAD/pgsql.30695/src/test/isolation/regression.diffs". A copy of the test summarythat you see above is saved in the file "/home/pgsql/buildfarm/buildroot/HEAD/pgsql.30695/src/test/isolation/regression.out". make: *** [installcheck] Error 1 ================== pgsql.30695/src/test/isolation/regression.diffs =================== *** /home/pgsql/buildfarm/buildroot/HEAD/pgsql.30695/src/test/isolation/expected/drop-index-concurrently-1.out 2012-12-0516:17:04.000000000 +0000 --- /home/pgsql/buildfarm/buildroot/HEAD/pgsql.30695/src/test/isolation/results/drop-index-concurrently-1.out 2012-12-0516:30:23.000000000 +0000 *************** *** 1,3 **** --- 1,4 ---- + PQconsumeInput failed: Parsed test spec with 3 sessions starting permutation: noseq prepi preps begin explaini explainsselect2 drop insert2 end2 selecti selects end *************** *** 37,40 **** 34 34 134 34 step end: COMMIT; - step drop: <... completed> --- 38,40 ---- ====================================================================== TRAP: FailedAssertion("!(rel->rd_refcnt > 0)", File: "relcache.c", Line: 1603) [50bf7643.6d63:2] LOG: server process (PID 28381) was terminated by signal 6: Aborted [50bf7643.6d63:3] DETAIL: Failed process was running: DROP INDEX CONCURRENTLY test_dc_data;
"Kevin Grittner" <kgrittn@mail.com> writes: > Stefan Kaltenbrunner wrote: >> seems like a rather odd failure in the isolation test (client) > Lines which might get the attention of interested parties: > TRAP: FailedAssertion("!(rel->rd_refcnt > 0)", File: "relcache.c", Line: 1603) Hah ... I'd looked at that report but managed to miss the TRAP entry. It's yet another silliness in the DROP INDEX CONCURRENTLY patch, which I'm now kicking myself for not noticing when I reviewed the patch last week: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e31d524867130d3c54b8d5f4c5ed59e2fcd07867 We really need to scare up another buildfarm member to run with -DCLOBBER_CACHE_ALWAYS, now that jaguar has stopped doing so. regards, tom lane
* Tom Lane wrote: > We really need to scare up another buildfarm member to run with > -DCLOBBER_CACHE_ALWAYS, now that jaguar has stopped doing so. I would be happy to do that on jaguarundi, in exchange for dialing down the build frequency from hourly to something a bit less ambitious. That machine is mostly idle anyway. -- Christian
On 12/06/2012 04:41 AM, Christian Ullrich wrote: > * Tom Lane wrote: > >> We really need to scare up another buildfarm member to run with >> -DCLOBBER_CACHE_ALWAYS, now that jaguar has stopped doing so. > > I would be happy to do that on jaguarundi, in exchange for dialing > down the build frequency from hourly to something a bit less > ambitious. That machine is mostly idle anyway. > The way to set this up is to add CPPFLAGS => '-DCLOBBER_CACHE_ALWAYS', to the config_env section of buildfarm config file. If you do this, you probably only want to run your animal on HEAD and run, say, once or twice a day. BTW, the buildfarm scripts contain mechanisms to prevent them from colliding with themselves, making it safe to run the scripts (especially run_branches.pl) very frequently without having to worry if a previously scheduled run has completed. cheers andrew
Christian Ullrich <chris@chrullrich.net> writes: > * Tom Lane wrote: >> We really need to scare up another buildfarm member to run with >> -DCLOBBER_CACHE_ALWAYS, now that jaguar has stopped doing so. > I would be happy to do that on jaguarundi, in exchange for dialing down > the build frequency from hourly to something a bit less ambitious. That > machine is mostly idle anyway. Sure, once or twice a day would be fine. (I think jaguar was only doing it once a day.) regards, tom lane