Re: Microvacuum support for Hash Index
От | Ashutosh Sharma |
---|---|
Тема | Re: Microvacuum support for Hash Index |
Дата | |
Msg-id | CAE9k0P=9ftuLnHWvhL+NKHD+tT+yPqi+G4ec4kxEiwEOF1tyrQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Microvacuum support for Hash Index (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Microvacuum support for Hash Index
|
Список | 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.
Вложения
В списке pgsql-hackers по дате отправления: