Re: segfault with plproxy - Mailing list pgsql-general

From Filip Rembiałkowski
Subject Re: segfault with plproxy
Date
Msg-id CAP_rww=udPOktRJEhvdKJAt3pvHN__WD4zUW0N7HUKH_ha6VAw@mail.gmail.com
Whole thread Raw
In response to Re: segfault with plproxy  (Marko Kreen <markokr@gmail.com>)
Responses Re: segfault with plproxy
List pgsql-general
W dniu 19 grudnia 2011 10:39 użytkownik Marko Kreen <markokr@gmail.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?

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.

#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?


regards,
Filip

pgsql-general by date:

Previous
From: Roger Leigh
Date:
Subject: Escaping input from COPY
Next
From: Filip Rembiałkowski
Date:
Subject: Re: segfault with plproxy