Re: BUG #5669: server process was terminated by exception 0xC0000005 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #5669: server process was terminated by exception 0xC0000005
Date
Msg-id 27203.1285173564@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #5669: server process was terminated by exception 0xC0000005  (Andrew Geery <andrew.geery@gmail.com>)
Responses Re: BUG #5669: server process was terminated by exception 0xC0000005  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-bugs
Andrew Geery <andrew.geery@gmail.com> writes:
> The schema below crashes pretty reliably for me.

OK ... so the problem is that the function uses the pg_settings view,
which results in calling show_all_settings(), and in particular it
runs show_session_authorization(), which then dumps core because
session_authorization_string is NULL in an autovacuum process.

As far as a fix for the crash goes, I'm not sure if it'd be better to
try to make show_session_authorization() return some sort of default
value in this scenario, or to try to ensure that the variable has been
set to something valid before we start running user-supplied code.
In either case the problem is potentially wider than this one function
and variable.  Thoughts anyone?

As far as the function itself goes, ISTM you ought to rethink it,
because this looks like the very opposite of immutable to me:

> 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;

That's no excuse for the backend crashing, of course, but I would not
be surprised at all if you end up with corrupt indexes due to the
allegedly-immutable value changing.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Andrew Geery
Date:
Subject: Re: BUG #5669: server process was terminated by exception 0xC0000005
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #5669: server process was terminated by exception 0xC0000005