Re: Bug in gin insert redo code path during re-compression of empty gin data leaf pages
Alexander Korotkov <a.korotkov@postgrespro.ru>
From: Alexander Korotkov <a.korotkov@postgrespro.ru>
To: sivasubr@amazon.com
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-07-18T08:59:02Z
Lists: pgsql-hackers
Hi! On Wed, Jul 18, 2018 at 1:40 AM R, Siva <sivasubr@amazon.com> wrote: > We came across an issue during replay of a gin insert record on a pre-9.4 > uncompressed data leaf page that does not have any items in it. The engine > version where the replay is done is 9.6.3. The redo logic attempts to > compress the existing page items before trying to insert new items from > the WAL record[1]. In this particular case, we noticed that if the data > leaf page does not have any items in it (see below on how such a page can > be present), the compression should not be attempted as the algorithm > expects the page to have at least one item [2]. This will lead to incorrect > data size set on the page and also makes the assertion that expects npacked > and nuncompressed to be equal, false [3]. > > In Postgres 9.3, when the gin posting tree is vacuumed, the pages that are > in the leftmost and rightmost branches are not deleted [4]. These empty > pages can be part of the database after upgrading to 9.6.3. We verified > this by doing the following test: > Thank you for reporting this bug. At the first glance it seems that your proposed fix is correct. I'll review it in more details and commit. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Commits
-
Fix handling of empty uncompressed posting list pages in GIN
- 608793266dbb 11.0 landed
- 9c6a676c4ced 9.4.19 landed
- 3c09b032afe5 9.5.14 landed
- 44b550e0d9a5 9.6.10 landed
- 0d26812a4331 10.5 landed
- 309765fa1e31 12.0 landed