| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PANIC: wrong buffer passed to visibilitymap_clear |
| Date: | 2021-04-13 01:54:44 |
| Message-ID: | CAH2-Wzkdo+rvUkJcV8=CG8KdJzq7Sjw2Yc+c89nDL0avkLyAyA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Apr 12, 2021 at 6:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thanks for looking it over. Do you have an opinion on whether or not
> to back-patch? As far as we know, these bugs aren't exposed in the
> back branches for lack of code that would set the all-visible flag
> without superexclusive lock. But I'd still say that heap_update
> is failing to honor its API contract in these edge cases, and that
> seems like something that could bite us after future back-patches.
If we assume that a scenario like the one we've been debugging can
never happen in the backbranches, then we must also assume that your
fix has negligible risk in the backbranches, because of how it is
structured. And so I agree -- I lean towards backpatching.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | James Coleman | 2021-04-13 02:07:16 | Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays |
| Previous Message | Tom Lane | 2021-04-13 01:33:19 | Re: PANIC: wrong buffer passed to visibilitymap_clear |