Re: Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-11-03T10:04:28Z
Lists: pgsql-hackers
Tom Lane wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > > Rather than remove the capability, I'd be inclined to make > > brin_summarize_new_values summarize the final partial range, and have > > VACUUM not do it. Would that be too inconsistent? > > That doesn't really get you out of the problem that this is an abuse of > the relation extension lock, and is likely to cause issues when people > try to optimize that locking mechanism. Right. > Why is it that the regular technique doesn't work, ie create a placeholder > tuple and let it get added to by any insertions that happen? The problem is that we determine relation size (and scan stop point) before inserting the placeholder tuple, so any relation extension that occurs after we read the size is not covered by the scan. The reason we do this is to avoid calling RelationGetNumberOfBlocks once for each range, since it's known to be very expensive. Maybe a solution is to call RelationGetNumberOfBlocks() after the placeholder tuple has been inserted, for the case where we would be scanning past end of relation; passing InvalidBlockNumber as stop point would indicate to do things that way. I'll try with that approach now. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Fix BRIN summarization concurrent with extension
- ec42a1dcb30d 11.0 landed
- cf0612aa2c8f 9.5.10 landed
- bd8e2b3cf4cf 9.6.6 landed
- 37a856567c04 10.1 landed
-
Fix corner-case errors in brin_doupdate().
- 62a16572d571 11.0 landed
- a43cd427e703 9.6.6 landed
- 43276abc6f7e 9.5.10 landed
- 97ba7b8c87e1 10.1 landed
-
Rewrite PageIndexDeleteNoCompact into a form that only deletes 1 tuple.
- 24992c6db9fd 10.0 cited
-
Invent PageIndexTupleOverwrite, and teach BRIN and GiST to use it.
- b1328d78f88c 10.0 cited
-
Close some holes in BRIN page assignment
- ccc4c074994d 9.6.0 cited