Hi Pavel,
Thanks for you help.
The code works ok on my database too when I call the procedure only once
sequentially. I hit the segmentation fault consistently when I try to call
the proc concurrently.
This is the actual code I am calling from within the procedure:
UPDATE activity
SET media_uri =
Hi Pavel,
I've just tried to reproduce the bug using your setup script and it doesn't
cause the seg fault.
We have copied one table: activity, from our code base on to a brand new db
(on a laptop so independent of any hardware issues), and we are using that
to test with.
I'm thinking there may so
Belinda Cussen writes:
> The code works ok on my database too when I call the procedure only once
> sequentially. I hit the segmentation fault consistently when I try to call
> the proc concurrently.
What do you mean by "concurrently"? There is no multithreading within
Postgres backends, and it'
Belinda Cussen writes:
> I've managed to produce this fault consistently now.
> Below is the simplified code:
> CREATE TABLE foo_1 (id int primary key,media_uri TEXT);
> INSERT INTO foo_1(id) SELECT i FROM generate_series(1,100) g(i);
> CREATE OR REPLACE FUNCTION bb_crash_db_5 () RETURNS TEX
Hi there,
I've managed to produce this fault consistently now.
I have a procedure which is passing in an array as a variable - rather than
using an array within a table column as in your example Pavel.
I then update a table based on the ids which are passed in in this array.
I have created a sim
Thanks!
On 28 November 2011 14:30, Tom Lane wrote:
> Belinda Cussen writes:
> > I've managed to produce this fault consistently now.
> > Below is the simplified code:
>
> > CREATE TABLE foo_1 (id int primary key,media_uri TEXT);
> > INSERT INTO foo_1(id) SELECT i FROM generate_series(1,100)
