Skip site navigation (1) Skip section navigation (2)

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

From: Andrew Geery <andrew(dot)geery(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5669: server process was terminated by exception 0xC0000005
Date: 2010-09-22 15:21:51
Message-ID: AANLkTimtyn=8aR8ES2KZUPD7LZHQQq9coCm6KNof_yxS@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugs
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 = '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(at)commandprompt(dot)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?  Please see
> http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_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
>
> --
> Álvaro Herrera <alvherre(at)commandprompt(dot)com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-09-22 15:58:28
Subject: Re: BUG #5669: server process was terminated by exception 0xC0000005
Previous:From: Tom LaneDate: 2010-09-22 13:59:20
Subject: Re: BUG #5662: Incomplete view

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group