| 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:52:30 |
| Message-ID: | 741234.1664574750@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
I wrote:
> 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.
Concretely, about like this.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| fix-RelationGetBufferForTuple-some-more.patch | text/x-diff | 2.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-09-30 21:56:11 | Re: pgsql: Avoid improbable PANIC during heap_update. |
| Previous Message | Peter Geoghegan | 2022-09-30 21:39:20 | Re: pgsql: Avoid improbable PANIC during heap_update. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-09-30 21:56:11 | Re: pgsql: Avoid improbable PANIC during heap_update. |
| Previous Message | Peter Eisentraut | 2022-09-30 21:51:04 | Re: [RFC] building postgres with meson - v13 |