Re: BUG #9464: PANIC with 'failed to re-find shared lock object'
От | Peter LaDow |
---|---|
Тема | Re: BUG #9464: PANIC with 'failed to re-find shared lock object' |
Дата | |
Msg-id | CAN8Q1EcttCT+sk-+gBERGb8BALh2MVkbVH=WW0PSbzvO1EeVzQ@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #9464: PANIC with 'failed to re-find shared lock object' (petela@gocougs.wsu.edu) |
Список | pgsql-bugs |
On Thu, Mar 6, 2014 at 4:56 PM, <petela@gocougs.wsu.edu> wrote: > -- Add the schema to the search path. Note that selecting from a table, > -- even if the result is unused, exhibits the problem. It seems to be > -- a select coupled with a set_config() that causes problems (of course > -- paired with our C extension). > CREATE OR REPLACE FUNCTION public.set_schema( ) > RETURNS VOID AS $$ > DECLARE > bar TEXT; > BEGIN > SELECT schema_name INTO bar FROM public.dummy_schema; > PERFORM pg_catalog.set_config('search_path', 'schema_16,public', > false); > END; > $$ LANGUAGE plpgsql VOLATILE STRICT SECURITY DEFINER; A bit more clarification. After sending this, we tweaked the set_schema() function a bit and determined the set_config() is irrelelvant. Just a simple select is enough to cause the problem, i.e.: CREATE OR REPLACE FUNCTION public.set_schema( ) RETURNS VOID AS $$ DECLARE bar TEXT; BEGIN SELECT schema_name INTO bar FROM public.dummy_schema; END; $$ LANGUAGE plpgsql VOLATILE STRICT SECURITY DEFINER; Follow this up with: psql -c "select set_schema(); select schema_16.myfoo(true);" And we get the panic. Thanks, Pete
В списке pgsql-bugs по дате отправления: