Re: GiST VACUUM
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Костя Кузнецов <chapaev28@ya.ru>
Date: 2018-07-29T09:04:35Z
Lists: pgsql-hackers
On Tue, Jul 24, 2018 at 6:04 AM, Andrey Borodin <x4mmm@yandex-team.ru> wrote: >> 21 июля 2018 г., в 17:11, Andrey Borodin <x4mmm@yandex-team.ru> написал(а): >> <0001-Physical-GiST-scan-in-VACUUM-v13.patch> > > Just in case, here's second part of patch series with actual page deletion. Hi Andrey, Cfbot says: https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.7146 That's because you declared a new variable after some other statements. You can't do that in old school C89. https://travis-ci.org/postgresql-cfbot/postgresql/builds/409401951 That segfaulted here: #0 0x00000000004ab620 in setinternal (state=<optimized out>, state=<optimized out>, blkno=368) at gistvacuum.c:44 44 state->internalPagesMap[blkno / 8] |= 1 << (blkno % 8); internalPagesMap was NULL, or pointed to memory that was too small and happened to be near an unmapped region (unlikely?), or was some other corrupted address? -- Thomas Munro http://www.enterprisedb.com
Commits
-
Use full 64-bit XID for checking if a deleted GiST page is old enough.
- fb5344c969af 12.0 landed
- 6655a7299d83 13.0 landed
-
Refactor checks for deleted GiST pages.
- e2e992c93145 12.0 landed
- 9eb5607e6993 13.0 landed
-
Delete empty pages during GiST VACUUM.
- 7df159a620b7 12.0 landed
-
Scan GiST indexes in physical order during VACUUM.
- fe280694d0d4 12.0 landed
-
Prevent GIN deleted pages from being reclaimed too early
- 52ac6cd2d0cd 12.0 cited