| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
| Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Avoid improbable PANIC during heap_update. |
| Date: | 2022-09-30 21:28:51 |
| Message-ID: | 692791.1664573331@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> writes:
> Just to confirm I saw this on RC1
Ugh ... I think I see the problem. There's still one path through
RelationGetBufferForTuple that fails to guarantee that it's acquired
a vmbuffer pin if the all-visible flag becomes set in the otherBuffer.
Namely, if we're forced to extend the relation, then we deal with
vm pins when ConditionalLockBuffer(otherBuffer) fails ... but not
when it succeeds. I think the fix is just to move the last
GetVisibilityMapPins call out of the "if
(unlikely(!ConditionalLockBuffer(otherBuffer)))" stanza.
It'd still be good to have a test case for this ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2022-09-30 21:39:20 | Re: pgsql: Avoid improbable PANIC during heap_update. |
| Previous Message | Tom Lane | 2022-09-30 20:51:20 | Re: pgsql: Avoid improbable PANIC during heap_update. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2022-09-30 21:39:20 | Re: pgsql: Avoid improbable PANIC during heap_update. |
| Previous Message | David Zhang | 2022-09-30 20:54:17 | Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit |