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

Re: Crash on UPDATE in 7.0beta3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Crash on UPDATE in 7.0beta3
Date: 2000-04-02 17:06:05
Message-ID: 3438.954695165@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Magnus Hagander <mha(at)sollentuna(dot)net> writes:
> When running multiple concurrent backends on my benchmark database, I see
> consistent crashing when running with 8 clients, and sporadic crashes when
> running with 4. After the crash, at least one index is broken, so if I run
> it again, it will crash on that. When I rebuild my indexes, I get back to
> the same crash.
> It dies on the same query every time (but only when I have many concurrent
> backends - I can run it "alone" from psql without any problem). 

What are the other backends doing?

After chasing this logic a little bit, my suspicion is focused on
ExecIndexReScan at about nodeIndexscan.c:342.  If an inner indexscan
is restarted in the context of EvalPlanQual (which, in fact, is exactly
where we are according to the backtrace) then this code returns without
doing much, and in particular without setting the indexscan node's
cs_ExprContext->ecxt_outertuple from the outer plan's value.  Perhaps
the next three lines ought to happen before testing for the PlanQual
case, instead of after (Vadim, what do you think?).  But I don't
understand why having other backends running concurrently would affect
this.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-04-02 17:30:05
Subject: Re: Crash on UPDATE in 7.0beta3
Previous:From: Bruce MomjianDate: 2000-04-02 16:36:58
Subject: Re: slow join on postgresql6.5

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