strange isolation test buildfarm failure on guaibasaurus

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 summary that 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-05 16:17:04.000000000 +0000
--- /home/pgsql/buildfarm/buildroot/HEAD/pgsql.30695/src/test/isolation/results/drop-index-concurrently-1.out 2012-12-05 16:30:23.000000000 +0000
***************
*** 1,3 ****
--- 1,4 ----
+ PQconsumeInput failed: 
  Parsed test spec with 3 sessions
  
  starting permutation: noseq prepi preps begin explaini explains select2 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;

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

"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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers