Re: Microvacuum support for Hash Index - Mailing list pgsql-hackers

From Ashutosh Sharma
Subject Re: Microvacuum support for Hash Index
Date
Msg-id CAE9k0P=9ftuLnHWvhL+NKHD+tT+yPqi+G4ec4kxEiwEOF1tyrQ@mail.gmail.com
Whole thread Raw
In response to Re: Microvacuum support for Hash Index  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Microvacuum support for Hash Index  (Jesper Pedersen <jesper.pedersen@redhat.com>)
List pgsql-hackers
Hi,

> While replaying the delete/vacuum record on standby, it can conflict
> with some already running queries.  Basically the replay can remove
> some row which can be visible on standby.  You need to resolve
> conflicts similar to what we do in btree delete records (refer
> btree_xlog_delete).

Agreed. Thanks for putting this point. I have taken care of it in the
attached v2 patch.

> + /*
> + * Write-lock the meta page so that we can decrement
> + * tuple count.
> + */
> + _hash_chgbufaccess(rel, metabuf, HASH_NOLOCK, HASH_WRITE);
> +
> + _hash_vacuum_one_page(rel, metabuf, buf, bucket_buf,
> +  (buf == bucket_buf) ? true : false);
> +
> + _hash_chgbufaccess(rel, metabuf, HASH_READ, HASH_NOLOCK);
>
> It seems here meta page lock is acquired for duration more than
> required and also it is not required when there are no deletable items
> on page. You can take the metapage lock before decrementing the count.

Ok. Corrected. Please refer to the attached v2 patch.


> Spurious space.  There are some other similar spurious white space
> changes in patch, remove them as well.

Corrected. Please refer attached v2 patch.

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: WAL consistency check facility
Next
From: Michael Paquier
Date:
Subject: Re: sequences and pg_upgrade