Re: Bug in gin insert redo code path during re-compression of emptygin data leaf pages
От | Alexander Korotkov |
---|---|
Тема | Re: Bug in gin insert redo code path during re-compression of emptygin data leaf pages |
Дата | |
Msg-id | CAPpHfdu9p8fpNsBCcdYxhBpXhe2_g3CDKjTKhh5BCEDuz6JdiA@mail.gmail.com обсуждение исходный текст |
Ответ на | Bug in gin insert redo code path during re-compression of empty gindata leaf pages ("R, Siva" <sivasubr@amazon.com>) |
Ответы |
Re: Bug in gin insert redo code path during re-compression of emptygin data leaf pages
|
Список | 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
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: