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 19:03:45
Message-ID: F7ACA758-1E26-4413-B6E3-DFC5EA6B370E@bplglobal.net (view raw or flat)
Thread:
Lists: pgsql-bugs
On Jan 14, 2010, at 10:44 AM, Tom Lane wrote:

> Justin Pitts <jpitts(at)bplglobal(dot)net> writes:
>> On Jan 14, 2010, at 10:16 AM, Tom Lane wrote:
>>> The 100 temp table creations probably will do that just fine.
> 
>> Is there a way to verify this?
> 
> You could add an elog(LOG, "message") into ResetPlanCache so you could
> tell when it had been called.
> 

Done. Sometimes I see it, sometimes not.

>> I don't follow. Are you suggesting I begin another transaction on connection 1 with a read, and that
>> would provoke the crash?
> 
> Yes.  The rollback only sets the stage for the next transaction to try
> to use a snapshot that isn't there anymore.
> 

Oh, duh. A read from the same session that rolled-back. That didn't get it working (failing?) however.

Running concurrent instances of this test reliably provokes the crash on un-patched 8.4.2.
They do not provoke a crash with the patch. That's what i was looking for.

Thanks!

> 			regards, tom lane


In response to

pgsql-bugs by date

Next:From: Oleg JurtšenkoDate: 2010-01-14 20:22:53
Subject: Re: BUG #5235: Segmentation fault under high load through JDBC
Previous:From: Tim BunceDate: 2010-01-14 18:41:52
Subject: Re: Termination When Switching between PL/Perl and PL/PerlU

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