| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Robins Tharakan <tharakan(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: PANIC in heap_delete during ALTER TABLE |
| Date: | 2022-09-15 22:25:30 |
| Message-ID: | 84255ddfad9b98b37fec4d031c4853de344cddea.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, 2022-09-08 at 10:30 -0700, Jeff Davis wrote:
> I wasn't able to repro on 13, but Robins' report indicates that it's
> possible.
I looked again, and I still can't find a way to repro on 13,
specifically the sha1 you mentioned (7cdd0c2d7c).
heap_delete() lets go of its exclusive lock (but not pin) in a couple
places (just like on master). But it looks like all the places that set
PD_ALL_VISIBLE are doing so under a cleanup lock (unlike master), which
means that it can't change for the duration of heap_delete().
I'm hesitant to commit anything here if I can't repro the problem on
13. I must be missing something.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2022-09-15 22:39:25 | Re: PANIC in heap_delete during ALTER TABLE |
| Previous Message | David Rowley | 2022-09-15 21:45:02 | Re: huge memory of Postgresql backend process |