Re: Apparent deadlock 7.0.1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Grim <grim(at)ewtoo(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Apparent deadlock 7.0.1
Date: 2000-06-07 23:16:13
Message-ID: 5271.960419773@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Grim <grim(at)ewtoo(dot)org> writes:
> I have noticed a deadlock happening on 7.0.1 on updates.
> The backends just lock, and take up as much CPU as they can. I kill
> the postmaster, and the backends stay alive, using CPU at the highest
> rate possible. The operations arent that expensive, just a single line
> of update.
> Anyone else seen this? Anyone dealing with this?

News to me. What sort of hardware are you running on? It sort of
sounds like the spinlock code not working as it should --- and since
spinlocks are done with platform-dependent assembler, it matters...

> search=# create index search_word_te_index on search_word_te (word,wordnum);
> ERROR: btree: index item size 3040 exceeds maximum 2717
> What is this all about? It worked fine on 6.5.2

If you had the same data in 6.5.2 then you were living on borrowed time.
The btree code assumes it can fit at least three keys per page, and if
you have some keys > 1/3 page then sooner or later three of them will
need to be stored on the same page. 6.5.2 didn't complain in advance,
it just crashed hard when that situation came up. 7.0 prevents the
problem by not letting you store an oversized key to begin with.

(Hopefully all these tuple-size-related problems will go away in 7.1.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-06-07 23:21:15 Re: AW: AW: AW: Proposal for enhancements of privilege syst em
Previous Message Grim 2000-06-07 22:07:37 Apparent deadlock 7.0.1