Re: BUG #9464: PANIC with 'failed to re-find shared lock object' - Mailing list pgsql-bugs

From Peter LaDow
Subject Re: BUG #9464: PANIC with 'failed to re-find shared lock object'
Date
Msg-id CAN8Q1EcttCT+sk-+gBERGb8BALh2MVkbVH=WW0PSbzvO1EeVzQ@mail.gmail.com
Whole thread Raw
In response to BUG #9464: PANIC with 'failed to re-find shared lock object'  (petela@gocougs.wsu.edu)
List 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 by date:

Previous
From: petela@gocougs.wsu.edu
Date:
Subject: BUG #9464: PANIC with 'failed to re-find shared lock object'
Next
From: Tom Lane
Date:
Subject: Re: BUG #9464: PANIC with 'failed to re-find shared lock object'