Re: [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint - Mailing list pgsql-hackers

From Ashutosh Sharma
Subject Re: [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint
Date
Msg-id CAE9k0PnzxWOTZPQX39czsmQQbhvSaDTn4nXbxS17dYaka61f4g@mail.gmail.com
Whole thread Raw
In response to Re: [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sat, Apr 1, 2017 at 6:00 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Mar 31, 2017 at 6:09 PM, Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>> Well, That is another option but the main idea was to be inline with
>> the btree code.
>
> That's not a bad goal in principal, but _bt_killitems() doesn't have
> any similar argument.

It was there but later got removed with some patch (may be the patch
for reducing pinning and buffer content lock for btree scans). The
following commit has this changes.

commit 09cb5c0e7d6fbc9dee26dc429e4fc0f2a88e5272
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Sun May 7 01:21:30 2006 +0000

>
> (Also, speaking of consistency, why did we end up with
> _hash_kill_items, with an underscore between kill and items, and
> _bt_killitems, without one?)

That is just to follow the naming convention in hash.h Please check
the review comments for this at - [1].

>
>> Moreover, I am not sure if acquiring lwlock inside
>> hashendscan (basically the place where we are trying to close down the
>> things) would look good.
>
> Well, if that's not a good thing to do, hiding it inside some other
> function doesn't make it better.

okay, agreed. I will submit the patch very shortly.


[1] - https://www.postgresql.org/message-id/cf6abd8a-77b5-f1c7-8e50-5bef461e0522%40redhat.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [POC] A better way to expand hash indexes.
Next
From: Andres Freund
Date:
Subject: Re: logical replication launcher crash on buildfarm