transforms vs. CLOBBER_CACHE_ALWAYS - Mailing list pgsql-hackers

From Andrew Dunstan
Subject transforms vs. CLOBBER_CACHE_ALWAYS
Date
Msg-id 55427924.9090806@dunslane.net
Whole thread Raw
Responses Re: transforms vs. CLOBBER_CACHE_ALWAYS
Re: transforms vs. CLOBBER_CACHE_ALWAYS
List 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

Attachment

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: ERROR: unexpected data beyond EOF
Next
From: Pavel Stehule
Date:
Subject: Re: Faster setup_param_list() in plpgsql