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