From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Andrey Borodin <amborodin86(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> |
Subject: | Re: regression coverage gaps for gist and hash indexes |
Date: | 2023-03-31 16:15:33 |
Message-ID: | 20230331161533.j3ejpnwti4jf2n22@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-03-31 10:45:51 +0300, Andrey Borodin wrote:
> On Fri, Mar 31, 2023 at 8:07 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> >
> > I was working on committing patch 0001 from [1] and was a bit confused about
> > some of the changes to the WAL format for gist and hash index vacuum. It
> > looked to me that the changed code just flat out would not work.
> >
> > Turns out the problem is that we don't reach deletion for hash and gist
> > vacuum:
> >
> > gist:
> >
> > > Oh, I see. We apparently don't reach the gist deletion code in the tests:
> > > https://coverage.postgresql.org/src/backend/access/gist/gistxlog.c.gcov.html#674
> > > https://coverage.postgresql.org/src/backend/access/gist/gistxlog.c.gcov.html#174
> > >
> > > And indeed, if I add an abort() into , it's not reached.
> > >
> > > And it's not because tests use a temp table, the caller is also unreachable:
> > > https://coverage.postgresql.org/src/backend/access/gist/gist.c.gcov.html#1643
> >
>
> GiST logs deletions in gistXLogUpdate(), which is covered.
> gistXLogDelete() is only used for cleaning during page splits.
I am not sure what your point here is - deleting entries to prevent a page
split is deleting entries. What am I missing?
> propose refactoring GiST WAL to remove gistXLogDelete() and using
> gistXLogUpdate() instead.
I think we still would need to have coverage for gistprunepage(), even if
so. So that seems a separate issue.
I think what gist.sql is missing is a combination of delete, index scan (to
mark entries dead), new insertions (to trigger pruning to prevent page
splits).
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2023-03-31 16:45:19 | Re: BUG #17877: Referencing a system column in a foreign key leads to incorrect memory access |
Previous Message | Tom Lane | 2023-03-31 15:26:24 | Re: SELECT INTO without columns or star |