pgsql: Avoid improbable PANIC during heap_update, redux.
От | Tom Lane |
---|---|
Тема | pgsql: Avoid improbable PANIC during heap_update, redux. |
Дата | |
Msg-id | E1oePZG-000LuF-EM@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
Avoid improbable PANIC during heap_update, redux. Commit 34f581c39 intended to ensure that RelationGetBufferForTuple would acquire a visibility-map page pin in case the otherBuffer's all-visible bit had become set since we last had lock on that page. But I missed a case: when we're extending the relation, VM concerns were dealt with only in the relatively-less-likely case that we fail to conditionally lock the otherBuffer. I think I'd believed that we couldn't need to worry about it if the conditional lock succeeds, which is true for the target buffer; but the otherBuffer was unlocked for awhile so its bit might be set anyway. So we need to do the GetVisibilityMapPins dance, and then also recheck the page's free space, in both cases. Per report from Jaime Casanova. Back-patch to v12 as the previous patch was (although there's still no evidence that the bug is reachable pre-v14). Discussion: https://postgr.es/m/E1lWLjP-00006Y-Ml@gemulon.postgresql.org Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b93d7e6883d683ea35f4f5ea843222f47aacbaee Modified Files -------------- src/backend/access/heap/hio.c | 41 +++++++++++++++++++++++------------------ 1 file changed, 23 insertions(+), 18 deletions(-)
В списке pgsql-committers по дате отправления: