Skip site navigation (1) Skip section navigation (2)

Re: BUG #5269: postgres backend terminates with SIGSEGV

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 (view raw or flat)
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


In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-01-14 15:44:49
Subject: Re: BUG #5269: postgres backend terminates with SIGSEGV
Previous:From: Justin PittsDate: 2010-01-14 15:25:46
Subject: Re: BUG #5269: postgres backend terminates with SIGSEGV

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group