On Thu, Mar 27, 2014 at 10:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Maxim Boguk <maxim.boguk@gmail.com> writes:
> > select * from bt_page_items('transactions_pkey', 88472) where itemoffset
> in
> > (93,94);
> > itemoffset | ctid | itemlen | nulls | vars | data
> >
> ------------+-------------+---------+-------+------+-------------------------
> > 93 | (2413168,1) | 16 | f | f | 7c c2 2c 03 00 00
> 00 00
> > 94 | (2337931,0) | 16 | f | f | 7c c2 2c 03 00 00
> 00 00
>
> This is sort of what I expected. Surely reindexing the index will get
> rid of that bogus entry?
>
> regards, tom lane
>
Yep reindexing that particular index fixed problem.
But this index had been reindexed just 2 days ago in the same situation,
and now problem reappear (with different table row/index entries).
If problem reappear after the last reindex and with 9.3.4 version I will
investigate future.
It would be interesting know how simple integer btree index could have
entry with definitely wrong ctid?
It very strange for problem reappear with the only one table (there are
couple other tables in the database with similar load but with no issues at
all), it looks too selective and repeatable for a hardware glitch.
Kind Regards,
Maksym
