From: | Alain Picard <Alain(dot)Picard(at)memetrics(dot)com> |
---|---|
To: | Alain Picard <alain(dot)picard(at)memetrics(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Postgresql 7.1.3 not thread safe |
Date: | 2002-02-19 06:02:05 |
Message-ID: | 15473.59997.778821.630726@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>>>>> In article <15473(dot)43974(dot)509236(dot)142554(at)localhost(dot)localdomain>, Alain Picard <alain(dot)picard(at)memetrics(dot)com> writes:
ap> This contrived example is the simplest form I can reproduce the
ap> problem to. My actual application is written in lisp, and uses
ap> unixODBC to talk to postgresql, though I believe the above problem
ap> should be reproducible using any client. I might write a perl
ap> script using the DBD stuff to test this. If I can reproduce the
ap> problem there, I'll forward the script.
I've included such a script, and it does reproduce the problem.
Run it as follows
1) create the table as per the previous message
2) run two copies of the scripts CONCURRENTLY.
% ./bang.pl 20000 a 2000000 &
% ./bang.pl 20000 b 2000000 &
3) When both scripts have finished, run the query
select * from test_table
where data
!='bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb'
and
data !=
'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa';
in psql, which should return no records in postgres is working OK.
You may have to run with a higher number of hits,
or with more concurrent processes, to increase your chances
of failure, especially on slow machines.
Attachment | Content-Type | Size |
---|---|---|
bang.pl | application/octet-stream | 739 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Marden | 2002-02-19 18:41:23 | Dates and year 2000 |
Previous Message | Alain Picard | 2002-02-19 01:35:02 | Postgresql 7.1.3 not thread safe |