From: | Justin Pitts <jpitts(at)bplglobal(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgreSQL(dot)org |
Subject: | Re: BUG #5269: postgres backend terminates with SIGSEGV |
Date: | 2010-01-14 15:34:10 |
Message-ID: | 02566E30-5D4D-495F-A3B2-52899610854D@bplglobal.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Jan 14, 2010, at 10:16 AM, Tom Lane wrote:
> Justin Pitts <jpitts(at)bplglobal(dot)net> writes:
>> My guess is that I am not provoking a 'SI queue overrun'
>
> The 100 temp table creations probably will do that just fine.
>
Is there a way to verify this?
>> Am I completely off base about how this should be reproducing?
>
> Two points: the session you hope to have crash *must* be in serializable
> mode,
The 2 competing sessions doing the read/modify sequence on foo are set to SERIALIZABLE.
> and the crash would actually happen in the transaction after the
> one that's rolled back.
>
I don't follow. Are you suggesting I begin another transaction on connection 1 with a read, and that
would provoke the crash?
> The error doesn't have to be a serialization error, so in principle
> you should be able to make it fail with something as simple as
>
> begin;
> select 1/0;
> rollback;
> select * from foo;
>
> as long as the ROLLBACK is done with a prepared statement and you've
> forced a SI overrun since the ROLLBACK was prepared.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-01-14 15:44:49 | Re: BUG #5269: postgres backend terminates with SIGSEGV |
Previous Message | Justin Pitts | 2010-01-14 15:25:46 | Re: BUG #5269: postgres backend terminates with SIGSEGV |