From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
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-11 17:55:30 |
Message-ID: | 2691724.1618163730@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> I'm now inclined to think that we should toss every single line of that
> code, take RelationGetBufferForTuple out of the equation, and have just
> *one* place that rechecks for PageAllVisible having just become set.
> It's a rare enough case that optimizing it is completely not worth the
> code complexity and risk (er, reality) of hard-to-locate bugs.
Alternatively, we could do what you suggested and redefine things
so that one is only allowed to set the all-visible bit while holding
superexclusive lock; which again would allow an enormous simplification
in heap_update and cohorts. Either way, it's hard to argue that
heap_update hasn't crossed the complexity threshold where it's
impossible to maintain safely. We need to simplify it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-04-11 18:07:33 | Re: PANIC: wrong buffer passed to visibilitymap_clear |
Previous Message | Tom Lane | 2021-04-11 17:41:32 | Re: PANIC: wrong buffer passed to visibilitymap_clear |