Re: pgsql 10: hash indexes testing

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, AP <ap(at)zip(dot)com(dot)au>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql 10: hash indexes testing
Date: 2017-08-05 02:20:06
Message-ID: CA+TgmoaGR0kZcpXDfYbrBP45i-M+Q0SFmo-9CtWBWd3+1D0ZJw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 4, 2017 at 2:45 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> I have not done anything for this comment as it doesn't sound wrong to
> me. I think it is not making much sense in the current code and we
> can remove it or change it as part of the separate patch if you or
> others think so.

I don't get it. The comment claims we have to _hash_getnewbuf before
releasing the metapage write lock. But the function neither calls
_hash_getnewbuf nor releases the metapage write lock. It then goes on
to say that for this reason we pass the new buffer rather than just
the block number. However, even if it were true that we have to call
_hash_getnewbuf before releasing the metapage write lock, what does
that have to do with the choice of passing a buffer vs. a block
number?

Explain to me what I'm missing, please, because I'm completely befuddled!

(On another note, I committed these patches.)

--
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-08-05 02:44:14 Re: pg_stop_backup(wait_for_archive := true) on standby server
Previous Message Robert Haas 2017-08-05 02:05:56 Re: A bug in mapping attributes in ATExecAttachPartition()