Re: werid error"index row size 3040 exceeds btree maximum, 2712" occur randomly

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: werid error"index row size 3040 exceeds btree maximum, 2712" occur randomly
Date: 2013-10-14 20:09:25
Message-ID: 525C4F75.6070407@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

On 14.10.2013 05:47, Huang, Suya wrote:
> Hi,
>
> OK, first, I know the reason of this error “index row size 3040
> exceeds btree maximum, 2712” and know that we cannot create index on
> certain columns with size larger than 1/3 buffer page size.
>
> The question is, no matter if I deleted records that caused the
> problem or all records of the table, the error still occurred and
> would disappear after a while randomly, like 1 or 2 minutes or so.

I'd bet what you see is a caused by MVCC. The deleted records are not
deleted immediately, but marked as deleted and then eventually freed by
(auto)vacuum background process, once no other sessions need them.

But those records need to be indexed, as other sessions may still need
to access them (depending on the transaction isolation level used), so
we can't just skip them when creating the index.

See this for more details on this topic:
http://www.postgresql.org/docs/9.3/static/transaction-iso.html

Try running VACUUM on the table before creating the index, and make sure
there are no other connections accessing the table. That should do the
trick.

That being said, I wonder why you need to create a gin index on such
long values. Any particular reason why you decided not to use a MD5 hash
of the value, as suggested by the HINT message?

regards
Tomas

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurentius Purba 2013-10-14 20:18:06 Postgresql 9.0.13 core dump
Previous Message ChoonSoo Park 2013-10-14 16:28:49 Re: trigger without trigger call