From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM |
Date: | 2017-11-03 13:12:27 |
Message-ID: | 20171103131227.yemodljts2hn4ab5@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera wrote:
> 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.
Yeah, I think this approach results in better code. The attached patch
implements that, and it passes the test for me (incl. calling
brin_summarize_new_values concurrently with vacuum, when running the
insert; the former does include the final page range whereas the latter
does not.)
Tomas Vondra wrote:
> FWIW this patch fixes the issue for me - I can no longer reproduce the
> bitmapscan vs. seqscan result discrepancies (even with the extra UPDATE
> phase).
Thanks for testing! This confirms that the issue was correctly
identified. Would you try the current patch, which is better than the
other one? It's significantly different that I think it invalidates
prior testing.
Thanks!
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Fix-summarization-concurrent-with-relation-extens.patch | text/plain | 7.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-11-03 13:19:05 | Re: [PATCH] A hook for session start |
Previous Message | Thomas Munro | 2017-11-03 13:05:49 | LDAPS |