barnacle (running CLOBBER_CACHE_RECURSIVELY) seems stuck since November

Hi,

I've been checking progress on barnacle, one of the animals running with
CLOBBER_CACHE_RECURSIVELY. It's running for ~170 days (250k minutes).

This time I've however checked the log, and what caught my eye is that
the last log message is from November. There were regular messages until
then (a few messages per day), but since Nov 19 there's nothing.

The last few messages are these:

2014-11-28 22:19:24 CET 7953 [540097d4.1f11:532] LOG:  statement: CREATE
FUNCTION city_insert() RETURNS trigger LANGUAGE plpgsql AS $$
2014-11-28 22:19:27 CET 7953 [540097d4.1f11:533] LOG:  statement: CREATE
TRIGGER city_insert_trig INSTEAD OF INSERT ON city_view
2014-11-28 22:25:13 CET 7953 [540097d4.1f11:534] LOG:  statement: CREATE
FUNCTION city_delete() RETURNS trigger LANGUAGE plpgsql AS $$
2014-11-28 22:25:15 CET 7953 [540097d4.1f11:535] LOG:  statement: CREATE
TRIGGER city_delete_trig INSTEAD OF DELETE ON city_view
2014-11-29 03:10:01 CET 7953 [540097d4.1f11:536] LOG:  statement: CREATE
FUNCTION city_update() RETURNS trigger LANGUAGE plpgsql AS $$
2014-11-29 03:10:03 CET 7953 [540097d4.1f11:537] LOG:  statement: CREATE
TRIGGER city_update_trig INSTEAD OF UPDATE ON city_view
2014-11-29 07:44:50 CET 7953 [540097d4.1f11:538] LOG:  statement: INSERT
INTO city_view(city_name) VALUES('Tokyo') RETURNING *;

which matches commands halfway-through 'triggers' tests.

There are currently two queries running - one from 'triggers', one from
'updatable_views':

-[ RECORD 1 ]----+----------------------------------------------
 datid            | 16384
 datname          | regression
 pid              | 7953
 usesysid         | 10
 usename          | pgbuild
 application_name | pg_regress
 client_addr      |
 client_hostname  |
 client_port      | -1
 backend_start    | 2014-08-29 17:10:12.243979+02
 xact_start       | 2014-11-29 07:44:50.452678+01
 query_start      | 2014-11-29 07:44:50.452678+01
 state_change     | 2014-11-29 07:44:50.45268+01
 waiting          | f
 state            | active
 backend_xid      |
 backend_xmin     | 3989
 query            | INSERT INTO city_view(city_name) VALUES('Tokyo')
RETURNING *;
 -[ RECORD 2 ]----+----------------------------------------------
 datid            | 16384
 datname          | regression
 pid              | 7956
 usesysid         | 10
 usename          | pgbuild
 application_name | pg_regress
 client_addr      |
 client_hostname  |
 client_port      | -1
 backend_start    | 2014-08-29 17:10:12.272223+02
 xact_start       | 2014-10-06 15:35:25.822488+02
 query_start      | 2014-10-06 15:35:25.822488+02
 state_change     | 2014-10-06 15:35:25.822491+02
 waiting          | f
 state            | active
 backend_xid      |
 backend_xmin     | 3862
 query            | UPDATE rw_view2 SET b='Row three' WHERE a=3 RETURNING *;

Top currently looks like this:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7956 pgbuild   20   0  242m  13m  10m R 98.8  0.2 251152:27 postgres:
pgbuild regression [local] UPDATE
 7953 pgbuild   20   0 1023m 785m  11m R 98.4 10.0 248806:18 postgres:
pgbuild regression [local] INSERT

Both backends started on August 29, but the 'updatable_views' query is
running since October 6. 5 months seems like a rather long runtime, even
with CLOBBER_CACHE_RECURSIVELY).

Not sure if it's relevant, but this is the machine with Intel C compiler
(2013).

Attached is a memory context info for the 7953 backend (with more than
1GB VIRT) - not sure if it's relevant, so just in case.


--
Tomas Vondra                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services