Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processingBRIN indexes in VACUUM
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processingBRIN indexes in VACUUM |
Дата | |
Msg-id | 20171031181053.xh7hzminpv6rvwr2@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM
|
Список | pgsql-hackers |
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). I think what we should do is rethink the locking considerations in brin_doupdate vs. brinGetTupleForHeapBlock, and how they are used in summarize_range and brininsert. In summarize_range, instead of hoping that in some cases we will not need to re-obtain the placeholder tuple, just do that in all cases keeping the buffer locked until the tuple is updated. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: