| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic |
| Date: | 2021-06-09 20:45:32 |
| Message-ID: | CAH2-Wzk9O+Oe4cmHCVzTY=mwcHn_hKvRUi8obinOyebtMPPbVw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 9, 2021 at 11:45 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Good find!
+1
> > The attached patch fixes this inconsistency
>
> I think I prefer applying the fix and the larger changes separately.
I wonder if it's worth making the goto inside lazy_scan_prune verify
that the heap tuple matches what we expect. I'm sure that we would
have found this issue far sooner if that had been in place already.
Though I'm less sure of how much value adding such a check has now.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhihong Yu | 2021-06-09 20:45:52 | Re: alter table set TABLE ACCESS METHOD |
| Previous Message | Robert Haas | 2021-06-09 20:31:53 | Re: Adjust pg_regress output for new long test names |