Re: segfault with plproxy

On Mon, Dec 19, 2011 at 01:05:20PM +0100, Filip Rembiałkowski wrote:
> W dniu 19 grudnia 2011 10:39 użytkownik Marko Kreen <markokr(at)gmail(dot)com> napisał:
> > On Sat, Dec 17, 2011 at 10:25:40PM +0100, Filip Rembiałkowski wrote:
> >> Following scrip causes segmentation fault. Any ideas why / how to diagnose?
> >
> >> create table part0.users( check(id%2=0) ) inherits (public.users);
> >> create table part1.users( check(id%2=1) ) inherits (public.users);
> >> create or replace function public.list_users(condition text)
> >
> >> select * from public.list_users('%xyz%'); -- crash with segfault
> >
> > It seems you are making plproxy call public.list_users() recursively.
> > Postgres probably OOM-s somewhere then.
> >
> > Either move plproxy function to some other db, or use
> > TARGET/SELECT to pick different target function.
>
>
> Thanks Marko,
>
> So is this "single-database, schemas mimic nodes" setup possible to
> achieve at all?

Yes, you just need to avoid calling same function recursively,
thats all.

>
> My intention was:
>
> #1. client calls func()
>
> #2. plproxy calls func() on part0. part0 is defined as 'user=part0' so
> it directs to part0.func() thanks to current_schema setting.

This won't work, plproxy always uses fully-qualified names.

> #3. plproxy calls func() on part1 (paralell to #2). logic same as #2.
>
> #4. plproxy combines result and sends it to client.
>
>
> Is schema a part of function signature?

Yes.

--
marko