barnacle (running CLOBBER_CACHE_RECURSIVELY) seems stuck since November
От | Tomas Vondra |
---|---|
Тема | barnacle (running CLOBBER_CACHE_RECURSIVELY) seems stuck since November |
Дата | |
Msg-id | 550F41AE.4020408@2ndquadrant.com обсуждение исходный текст |
Ответы |
Re: barnacle (running CLOBBER_CACHE_RECURSIVELY) seems
stuck since November
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: