Re: Hash Indexes

On Mon, Dec 12, 2016 at 9:21 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> The reason is to make the operations consistent in master and standby.
> In WAL patch, for clearing the SPLIT_CLEANUP flag, we write a WAL and
> if we don't release the lock after writing a WAL, the operation can
> appear on standby even before on master. Currently, without WAL,
> there is no benefit of doing so and we can fix by using
> MarkBufferDirty, however, I thought it might be simpler to keep it
> this way as this is required for enabling WAL. OTOH, we can leave
> that for WAL patch. Let me know which way you prefer?

It's not required for enabling WAL. You don't *have* to release and
reacquire the buffer lock; in fact, that just adds overhead. You *do*
have to be aware that the standby will perhaps see the intermediate
state, because it won't hold the lock throughout. But that does not
mean that the master must release the lock.

>> I don't think we should be afraid to call MarkBufferDirty() instead of
>> going through these (fairly stupid) hasham-specific APIs.
>
> Right and anyway we need to use it at many more call sites when we
> enable WAL for hash index.

I propose the attached patch, which removes _hash_wrtbuf() and causes
those functions which previously called it to do MarkBufferDirty()
directly. Aside from hopefully fixing the bug we're talking about
here, this makes the logic in several places noticeably less
contorted.

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