Re: GiST insert algorithm rewrite
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, Teodor Sigaev <teodor@sigaev.ru>, Oleg Bartunov <oleg@sai.msu.su>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2010-11-30T10:02:50Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
New feature:
- 0ad7db4be4b1 7.1.1 cited
On 30.11.2010 11:55, Heikki Linnakangas wrote: > On 27.11.2010 21:31, Bruce Momjian wrote: >> Heikki Linnakangas wrote: >>> There's no on-disk format changes, except for the additional flag in the >>> page headers, so this does not affect pg_upgrade. However, if there's >>> any "invalid" keys in the old index because of an incomplete insertion, >>> the new code will not understand that. So you should run vacuum to >>> ensure that there's no such invalid keys in the index before upgrading. >>> Vacuum will print a message in the log if it finds any, and you will >>> have to reindex. But that's what it suggests you to do anyway. >> >> OK, pg_upgrade has code to report invalid gin and hash indexes because >> of changes between PG 8.3 and 8.4. Is this something we would do for >> 9.0 to 9.1? > > 9.1. The problem that started this whole thing is there in older > versions, but given the lack of real-life reports and the scale of the > changes required it doesn't seem wise to backport. Oh sorry, I read your question as "9.0 *or* 9.1". Only GiST indexes that have any "invalid" tuples in them n, as a result of a crash, need to be reindexed. That's very rare in practice, so we shouldn't invalidate all GiST indexes. I don't think there's any simple way to check whether reindex is required, so I think we have to just document this. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com