transforms vs. CLOBBER_CACHE_ALWAYS

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема transforms vs. CLOBBER_CACHE_ALWAYS
Дата
Msg-id 55427924.9090806@dunslane.net
обсуждение исходный текст
Ответы Re: transforms vs. CLOBBER_CACHE_ALWAYS  (Christian Ullrich <chris@chrullrich.net>)
Re: transforms vs. CLOBBER_CACHE_ALWAYS  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the plpython regression
tests. The only relevant commit seems to be the transforms feature.
Here's what it's been doing:

      pl_regression=# select * from pg_stat_activity where
    application_name = 'pg_regress';
    -[ RECORD 1 ]----+------------------------------
    datid            | 27438
    datname          | pl_regression
    pid              | 15434
    usesysid         | 10
    usename          | buildfarm
    application_name | pg_regress
    client_addr      |
    client_hostname  |
    client_port      | -1
    backend_start    | 2015-04-27 05:51:12.689281-04
    xact_start       | 2015-04-27 05:51:28.324329-04
    query_start      | 2015-04-27 05:51:28.324329-04
    state_change     | 2015-04-27 05:51:28.324341-04
    waiting          | f
    state            | active
    backend_xid      |
    backend_xmin     | 5540
    query            | SELECT cursor_plan();

I imagine it was in some sort of infinite loop. gdb says it's all in
src/backend/utils/cache/plancache.c, although not the same line each
time I run it.

I ended up killing it accidentally, but I hope this helps narrow the
problem down.

The buildfarm server rejected the report because the snapshot was so
old, but the relevant report is attached.

cheers

andrew

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: ERROR: unexpected data beyond EOF
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Faster setup_param_list() in plpgsql