Legacy GiST invalid tuples

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Legacy GiST invalid tuples
Date: 2018-07-04 05:49:31
Message-ID: 4B268317-6A20-4067-A207-E4C04932CA3B@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Hi, hackers!

There is bunch of code in current GiST implementation checking for GistTupleIsInvalid(). PostgreSQL since 9.1 do not create invalid tuples. Should we support this tuples forever?

Invalid tuples were created in case of crash during GiST page split. They were used as a recovery measure. During index scan invalid tuples are treated as unconditional match. Any update in subtree of such tuple will error with errhint("Please REINDEX it."). Any VACUUM will log same complaint (but succeed).

I think that there are two options:
1. Bold one: just assume that there are no more invalid tuples.
2. For v12 raise the severity to ERROR on any encounter, then goto option 1 for vNext

What is the purpose of dropping invalid tuples?
1. Make code cleaner
2. Free some spare bytes in t_tid for advancing GiST (for example, see my other patch on GiST intrapage indexing [0] )

Best regards, Andrey Borodin.

[0] https://www.postgresql.org/message-id/7780A07B-4D04-41E2-B228-166B41D07EEE@yandex-team.ru

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message chenhj 2018-07-04 06:21:25 When use prepared protocol, transaction will hold backend_xmin until the end of the transaction.
Previous Message Michael Paquier 2018-07-04 04:59:12 Re: [HACKERS] WAL logging problem in 9.4.3?