Tom Lane wrote:
>
> Grim <grim@ewtoo.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...
The hardware/software is:
Linux kernel 2.2.15 (SMP kernel)
Glibc 2.1.1
Dual Intel PIII/500
There are usually about 30 connections to the database at any one 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.
Ahhh, it was the tuple size, I thought it meant the number of records in
the index or something, seeing as coincidentally that was the biggest
table.
Deleted one row of 3K, and all works fine now, thanks!
~Michael