| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, pgsql-committers(at)lists(dot)postgresql(dot)org, Jeff Davis <pgsql(at)j-davis(dot)com> |
| Subject: | Re: pgsql: Avoid improbable PANIC during heap_update. |
| Date: | 2022-10-01 05:25:06 |
| Message-ID: | CAH2-WznqWF53P5YE2t_GF_UT+=F__w+_zORMYCN5iDt6PJeOig@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On Fri, Sep 30, 2022 at 10:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> How so? AFAICS these are exactly the same oversight, ie failure
> to deal with the all-visible bit getting set partway through the
> operation. You've explained how that can happen.
I thought that there might have been something protective about how
the loop would work in heap_update(), but perhaps that's not true. It
might just be that heap_update() does lots of stuff in between, so
it's less likely to be affected by this particular race (the race
which seems to be present in all versions).
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-10-01 06:28:43 | pgsql: doc: Fix some grammar and typos |
| Previous Message | Tom Lane | 2022-10-01 05:13:13 | Re: pgsql: Avoid improbable PANIC during heap_update. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2022-10-01 06:14:01 | Re: problems with making relfilenodes 56-bits |
| Previous Message | Tom Lane | 2022-10-01 05:13:13 | Re: pgsql: Avoid improbable PANIC during heap_update. |