Re: segfault of autovacuum process during restore - coredumps included - Mailing list pgsql-bugs

From Frank van Vugt
Subject Re: segfault of autovacuum process during restore - coredumps included
Date
Msg-id 200511282136.46128.ftm.van.vugt@foxi.nl
Whole thread Raw
In response to Re: segfault of autovacuum process during restore - coredumps included  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-bugs
Alvaro,

> Hum, I'm unable to reproduce the problem here; could you give me the
> code for the functions in the functional indexes for tables 164956 or
> 227469?  They must be non-trivial SQL functions AFAICT (I'm rather
> unable to figure out their shape based only on the backtrace.)

Obviously the oid's have changed ;), but the relid in frame 13 of the latest
backtrace:

#13 0x080febd6 in analyze_rel (relid=268480, vacstmt=0x4422f4a0) at
analyze.c:257

is referring to a table 'purchaseorder_line' which has one functional index
defined like this (taken from '\d' output):

    "purchaseorder_line_idx01" btree (salesorder_line_id)
    WHERE status_id <> pol_stat('POL_CANCELLED'::character varying)
        AND status_id <> pol_stat('POL_HANDLED'::character varying)

The pol_stat() function is a helper-function used to refer to statusses by
abbreviation instead of id and is defined as:

    CREATE OR REPLACE FUNCTION pol_stat(varchar)
        RETURNS int
        LANGUAGE 'sql'
        IMMUTABLE
        STRICT
        SECURITY INVOKER
        AS 'SELECT id FROM purchaseorder_line_status WHERE abbreviation = $1';


If you were interested in some other relid, just let me know.



--
Best,




Frank.

pgsql-bugs by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: On-line backup
Next
From: Frank van Vugt
Date:
Subject: Re: segfault of autovacuum process during restore - coredumps included