| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andrey Borodin <amborodin86(at)gmail(dot)com>, Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE |
| Date: | 2023-02-04 19:10:55 |
| Message-ID: | CAH2-Wzkrh1OmRy=xNQbx4Yb708j152tZ-oPKS1S7fNURVxKTOg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Feb 4, 2023 at 2:57 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Is there a good way to make breakage in the page recycling mechanism
> visible with gist? I guess to see corruption, I'd have to halt a scan
> before a page is visited with gdb, then cause the page to be recycled
> prematurely in another session, then unblock the first? Which'd then
> visit that page, thinking it to be in a different part of the tree than
> it actually is?
Yes. This bug is similar to an ancient nbtree bug fixed back in 2012,
by commit d3abbbeb.
> which clearly doesn't seem right.
>
> I just can't quite judge how bad that is.
It's really hard to judge, even if you're an expert. We're talking
about a fairly chaotic scenario. My guess is that there is a very
small chance of a very unpleasant scenario if you have a GiST index
that has regular page deletions, and if you use
vacuum_defer_cleanup_age. It's likely that most GiST indexes never
have any page deletions due to the workload characteristics.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nitin Jadhav | 2023-02-04 19:26:58 | Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl |
| Previous Message | Nathan Bossart | 2023-02-04 18:14:36 | Re: recovery modules |