Re: Fix parallel vacuum buffer usage reporting
Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
From: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
To: Alena Rybakina <lena.ribackina@yandex.ru>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-04-25T07:17:52Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix parallel vacuum buffer usage reporting.
- 5cd72cc0c501 17.0 landed
- f199436c1281 16.3 landed
- faba2f8f35df 15.7 landed
-
Use bump context for TID bitmaps stored by vacuum
- 8a1b31e6e596 17.0 cited
On Wed, Apr 24, 2024 at 4:01 PM Alena Rybakina <lena.ribackina@yandex.ru> wrote: > I tested the main postgres branch with and without your fix using a script > that was written by me. It consists of five scenarios and I made a > comparison in the logs between the original version of the master branch > and the master branch with your patch: > Hi! Thanks for the tests. I have attached a test file (vacuum_check_logs.sql) > Looking at the script, you won't trigger the problem. The reporting issue will only happen if there's a parallel index vacuum and it will only happen if there's at least 2 indexes [0]. You will need to create an additional index. The same script was run, but using vacuum verbose analyze, and I saw the > difference again in the fifth step: > with your patch: buffer usage: 32312 hits, 607 misses, 1566 dirtied > master: buffer usage: 32346 hits, 573 misses, 1360 dirtied > Isn't there a chance for the checkpointer to run during this time? That could make the conditions between the two runs slightly different and explain the change in buffer report. [0] https://github.com/postgres/postgres/blob/8a1b31e6e59631807a08a4e9465134c343bbdf5e/src/backend/access/heap/vacuumlazy.c#L2826-L2831