| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrey Borodin <amborodin86(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Subject: | Re: regression coverage gaps for gist and hash indexes |
| Date: | 2023-03-31 12:55:00 |
| Message-ID: | 389178.1680267300@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrey Borodin <amborodin86(at)gmail(dot)com> writes:
> On Fri, Mar 31, 2023 at 8:07 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Turns out the problem is that we don't reach deletion for hash and gist
>> vacuum:
> GiST logs deletions in gistXLogUpdate(), which is covered.
> gistXLogDelete() is only used for cleaning during page splits. I'd
> propose refactoring GiST WAL to remove gistXLogDelete() and using
> gistXLogUpdate() instead.
> However I see that gistXLogPageDelete() is not exercised, and is worth
> fixing IMO. Simply adding 10x more data in gist.sql helps, but I think
> we can do something more clever...
See also the thread about bug #16329 [1]. Alexander promised to look
into improving the test coverage in this area, maybe he can keep an
eye on the WAL logic coverage too.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/16329-7a6aa9b6fa1118a1%40postgresql.org
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Reid Thompson | 2023-03-31 13:39:00 | Re: FW: Add the ability to limit the amount of memory that can be allocated to backends. |
| Previous Message | Ashutosh Bapat | 2023-03-31 12:46:12 | Re: Infinite Interval |