Re: Write Ahead Logging for Hash Indexes

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Write Ahead Logging for Hash Indexes
Date: 2017-02-27 17:37:29
Message-ID: CA+Tgmoa0g0-cj8f7Xc5T=NoCwQtVPkftOZaUnwoQj1Jah4z7Ew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 16, 2017 at 8:16 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> Attached are refactoring patches. WAL patch needs some changes based
> on above comments, so will post it later.

After some study, I have committed 0001, and also committed 0002 and
0003 as a single commit, with only minor tweaks.

I haven't made a full study of 0004 yet, but I'm a bit concerned about
a couple of the hunks, specifically this one:

@@ -985,9 +962,9 @@ _hash_splitbucket_guts(Relation rel,

if (PageGetFreeSpace(npage) < itemsz)
{
- /* write out nbuf and drop lock, but keep pin */
- MarkBufferDirty(nbuf);
+ /* drop lock, but keep pin */
LockBuffer(nbuf, BUFFER_LOCK_UNLOCK);
+
/* chain to a new overflow page */
nbuf = _hash_addovflpage(rel, metabuf, nbuf,
(nbuf == bucket_nbuf) ? true : false);
npage = BufferGetPage(nbuf);

And also this one:

@@ -1041,17 +1024,6 @@ _hash_splitbucket_guts(Relation rel,
* To avoid deadlocks due to locking order of buckets, first lock the old
* bucket and then the new bucket.
*/
- if (nbuf == bucket_nbuf)
- {
- MarkBufferDirty(bucket_nbuf);
- LockBuffer(bucket_nbuf, BUFFER_LOCK_UNLOCK);
- }
- else
- {
- MarkBufferDirty(nbuf);
- _hash_relbuf(rel, nbuf);
- }
-
LockBuffer(bucket_obuf, BUFFER_LOCK_EXCLUSIVE);
opage = BufferGetPage(bucket_obuf);
oopaque = (HashPageOpaque) PageGetSpecialPointer(opage);

I haven't quite grasped what's going on here, but it looks like those
MarkBufferDirty() calls didn't move someplace else, but rather just
vanished. That would seem to be not good.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-02-27 17:39:40 Re: Creation of "Future" commit fest, named 2017-07
Previous Message Tom Lane 2017-02-27 17:27:48 Re: PATCH: two slab-like memory allocators