Re: BUG #5669: server process was terminated by exception 0xC0000005

I think I've tracked down the problem, although I haven't been able to
get a stack trace yet.  I'm afraid that it's my own stupidity, but I
still don't understand why this crashes the entire engine.

On the collection table, I have a FTS index.  I probably should have
defined the index this way:

create index ix_collection_name_fts on collection using
gin(to_tsvector('english', name));

but instead I defined it this way:

create index ix_collection_name_fts on collection using
gin(to_tsvector(get_fts_config_name(), name));

where the definition of the function is:

create or replace function get_fts_config_name() returns regconfig as $$
            select setting::regconfig from pg_settings
                where name =3D 'default_text_search_config';
        $$ language sql immutable;

Once I remove the bad FTS index and replaced it with the good index,
the server no longer crashes.

Reading about immutable functions here
[http://developer.postgresql.org/pgdocs/postgres/xfunc-volatility.html],
made it sound like the only problem with making a volatile function
immutable is that the query planner might do the wrong thing.  I
didn't realize it could have such drastic results...  Is it still
worth getting a stack trace or is this just a don't-ever-do-that
thing?

Thanks
Andrew

On Tue, Sep 21, 2010 at 5:50 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Andrew Geery's message of mar sep 21 16:37:20 -0400 2010:
>> Running the server in debug mode, I see the following before the
>> server crashes -- it looks like something goes wrong with
>> autovac_balance_cost when trying to analyze the collection table (that
>> was the table the inserts were being done into).
>>
>> Thanks
>
> Hmm, can you get a stack trace? =A0Please see
> http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_Postgr=
eSQL_backend_on_Windows
>
> Probably the easiest way to catch a dying autovacuum process is to set a
> very high value of vacuum_cost_delay, so that it sleeps for long enough
> that you can attach to it with the debugger before it dies.
>
> Thanks
>
> --
> =C1lvaro Herrera <alvherre@commandprompt.com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>