On Jan 14, 2010, at 10:16 AM, Tom Lane wrote: > Justin Pitts <jpi...@bplglobal.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
