| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Avoid improbable PANIC during heap_update. |
| Date: | 2022-09-30 21:56:11 |
| Message-ID: | 741997.1664574971@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Fri, Sep 30, 2022 at 2:28 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
> FWIW it seems possible that the Postgres 15 vacuumlazy.c work that
> added lazy_scan_noprune() made this scenario more likely in practice
> -- even compared to Postgres 14.
Could be, because we haven't seen field reports of this in v14 yet.
And there's still no hard evidence of a bug pre-14. Nonetheless,
I'm inclined to backpatch to v12 as 34f581c39 was.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2022-09-30 22:03:46 | Re: pgsql: Avoid improbable PANIC during heap_update. |
| Previous Message | Tom Lane | 2022-09-30 21:52:30 | Re: pgsql: Avoid improbable PANIC during heap_update. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-09-30 22:00:53 | Re: predefined role(s) for VACUUM and ANALYZE |
| Previous Message | Tom Lane | 2022-09-30 21:52:30 | Re: pgsql: Avoid improbable PANIC during heap_update. |