Re: Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Paquier <michael.paquier@gmail.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>,
PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-10-31T19:09:11Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Tom Lane wrote: >> I really don't understand how any of this "let's release the buffer >> lock and then take it back later" logic is supposed to work reliably. > So summarize_range first inserts the placeholder tuple, which is there > purposefully for other processes to update concurrently; then, without > blocking any other process, scan the page range and update the > placeholder tuple (this could take a long time, so it'd be a bad idea > to hold buffer lock for that long). Yeah, agreed, and your upthread point about avoiding deadlock when we need to take two buffer locks at the same time is also something that it's hard to see any other way around. Maybe we just have to find a way to make the existing structure work. The sticking point is that not only might the tuple we expected have been deleted, but someone could have put an unrelated tuple in its place. Are you confident that you can detect that and recover from it? If you're sure that brin_tuples_equal() is trustworthy for this purpose, then maybe we just have some run-of-the-mill bugs to find, like the off-the-end bug I spotted in brin_doupdate. There's apparently at least one more, but given the error message it must be something like not checking for a page to have turned into a revmap page. Shouldn't be too hard to find... regards, tom lane
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