| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-10-01 16:53:59 |
| Message-ID: | CAH2-WznYYsJxBYB1zvN_oA4zb_PGQdbF0x7TpJ-jFbDeJvPS1A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On Sat, Oct 1, 2022 at 9:35 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> Doesn't that deal with the case you brought up directly? heap_delete()
> can't get the exclusive lock until VACUUM releases its cleanup lock, at
> which point all-visible will be set. Then heap_delete() should notice
> in line 2509 and then pin the VM buffer. Right?
I now believe that you're right. I don't think that this code was ever
designed to rely on cleanup locks in any way; that was kind of an
accident all along. Even still, I'm not sure how I missed such an
obvious thing. Sorry for the misdirection.
Still, there has to be *some* reason why the bug could repro on 13.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-10-01 19:42:12 | pgsql: meson: windows: Determine path to tmp_install + prefix using mes |
| Previous Message | Jeff Davis | 2022-10-01 16:35:31 | Re: pgsql: Avoid improbable PANIC during heap_update. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-10-01 19:13:59 | Re: Question: test "aggregates" failed in 32-bit machine |
| Previous Message | Jeff Davis | 2022-10-01 16:35:31 | Re: pgsql: Avoid improbable PANIC during heap_update. |