| 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 | Resend email |
| 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
| 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? |