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)
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
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
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'
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
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 =
