Re: Hash Indexes
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Jesper Pedersen <jesper.pedersen@redhat.com>, Mithun Cy <mithun.cy@enterprisedb.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-12-06T12:00:27Z
Lists: pgsql-hackers
On Tue, Dec 6, 2016 at 1:29 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > > > I just occasionally insert a bunch of equal tuples, which have to be in > overflow pages no matter how much splitting happens. > > I am getting vacuum errors against HEAD, after about 20 minutes or so (8 > cores). > > 49233 XX002 2016-12-05 23:06:44.087 PST:ERROR: index "foo_index_idx" > contains unexpected zero page at block 64941 > 49233 XX002 2016-12-05 23:06:44.087 PST:HINT: Please REINDEX it. > 49233 XX002 2016-12-05 23:06:44.087 PST:CONTEXT: automatic vacuum of table > "jjanes.public.foo" > Thanks for the report. This can happen due to vacuum trying to access a new page. Vacuum can do so if (a) the calculation for maxbuckets (in metapage) is wrong or (b) it is trying to free the overflow page twice. Offhand, I don't see that can happen in code. I will investigate further to see if there is any another reason why vacuum can access the new page. BTW, have you done the test after commit 2f4193c3, that doesn't appear to be the cause of this problem, but still, it is better to test after that fix. I am trying to reproduce the issue, but in the meantime, if by anychance, you have a callstack, then please share the same. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Remove _hash_wrtbuf() in favor of calling MarkBufferDirty().
- 25216c989384 10.0 landed
-
Fix race introduced by 6d46f4783efe457f74816a75173eb23ed8930020.
- 2f4193c3509a 10.0 cited
-
Improve hash index bucket split behavior.
- 6d46f4783efe 10.0 landed
-
Reduce pinning and buffer content locking for btree scans.
- 2ed5b87f96d4 9.5.0 cited