Re: segfault in hot standby for hash indexes
Ashutosh Sharma <ashu.coek88@gmail.com>
From: Ashutosh Sharma <ashu.coek88@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-03-21T11:00:54Z
Lists: pgsql-hackers
Attachments
- corrected_block_id_reference_in_hash_vacuum_get_latestRemovedXid.patch (application/x-download) patch
Hi Jeff, On Tue, Mar 21, 2017 at 1:54 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Tue, Mar 21, 2017 at 1:28 PM, Jeff Janes <jeff.janes@gmail.com> wrote: >> Against an unmodified HEAD (17fa3e8), I got a segfault in the hot standby. >> > > I think I see the problem in hash_xlog_vacuum_get_latestRemovedXid(). > It seems to me that we are using different block_id for registering > the deleted items in xlog XLOG_HASH_VACUUM_ONE_PAGE and then using > different block_id for fetching those items in > hash_xlog_vacuum_get_latestRemovedXid(). So probably matching those > will fix this issue (instead of fetching block number and items from > block_id 1, we should use block_id 0). > Thanks for reporting this issue. As Amit said, it is happening due to block_id mismatch. Attached is the patch that fixes the same. I apologise for such a silly mistake. Please note that I was not able to reproduce the issue on my local machine using the test script you shared. Could you please check with the attached patch if you are still seeing the issue. Thanks in advance. -- With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com
Commits
-
Still more code review for single-page hash vacuuming.
- c4c51541e22b 10.0 landed
-
Another fix for single-page hash index vacuum.
- 9abbf4727de7 10.0 cited