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...
> 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