On Jan 14, 2010, at 10:44 AM, Tom Lane wrote:
> Justin Pitts 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
On Jan 14, 2010, at 10:16 AM, Tom Lane wrote:
> Justin Pitts 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 reproduc
As difficult as it was to reproduce the bug, I'd like a clear cut regression
test. The use case where it manifested is fairly rare in normal use - server
start after prolonged outage, where the queue of inbound device events is built
up enough to make serialization errors more likely.
On Jan 14
Justin Pitts 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.
> I don't follow. Are you s
Apologies for over-quoting on the previous message.
My approach to a regression test was this single-threaded test ( actual code at
bottom )
Connection 1 - implicitly autocommiting every statement
create a test table and populate it with a single row.
BTW --- from my own perspective, what is much more interesting is
testing time on your real application to make sure that you don't
see a crash any more. I am certain that I identified and fixed
*a* bug, what I'm less certain about is that it is actually what
you were hitting. The previous advice
Justin Pitts writes:
> My guess is that I am not provoking a 'SI queue overrun'
The 100 temp table creations probably will do that just fine.
> 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, and the
Sorry for the delay.
I am attempting to construct a JDBC test case that reproduces the problem.
I have installed the patch and have not seen the crash since.
On Jan 13, 2010, at 11:58 AM, Tom Lane wrote:
> I wrote:
>> After puzzling over this for many hours, I have a theory that seems to
>> fi
I wrote:
> After puzzling over this for many hours, I have a theory that seems to
> fit the facts.
I think the attached patch will fix it for you --- please test.
regards, tom lane
Index: src/backend/utils/cache/plancache.c
On Tue, 12 Jan 2010, Tom Lane wrote:
preparing something as trivial as a ROLLBACK is pretty silly so nobody
does it.
Actually the JDBC driver has been preparing BEGIN, COMMIT, and ROLLBACK
since the 8.0 release.
http://archives.postgresql.org/pgsql-jdbc/2006-10/msg00149.php
Kris Jurka
-
Justin Pitts writes:
> It went seriously heisenbug since I added %p. It took all day to crash it
> since I added that to the configuration. Except this latest crash is
> completely different - signal 6 ABRT, different place.
Specifically:
2010-01-13 01:50:42 UTC 5455 ERROR: snapshot reference
"Justin Pitts" writes:
> [ crash in CopySnapshot ]
This is a new one I think. Alvaro fixed some snapshot management issues
back in October, but if you're seeing it on 8.4.2 then that didn't fix
it :-(
> I am including a backtrace. Sanitizing a simple, clear repro case will take
> us some time,
The following bug has been logged online:
Bug reference: 5269
Logged by: Justin Pitts
Email address: justinpi...@gmail.com
PostgreSQL version: 8.4.2
Operating system: Debian Lenny 2.6.30-bpo.1-amd-64 kernel
Description:postgres backend terminates with SIGSEGV
Details:
13 matches
Mail list logo
