Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index
От | Shubham Barai |
---|---|
Тема | Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index |
Дата | |
Msg-id | CALxAEPvAo_MH7RnxMoV-x5AMFu2OOf1dToR9R+0ksM8jkH95dw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Список | pgsql-hackers |
On Sep 28, 2017 4:30 PM, "Alexander Korotkov" <a.korotkov@postgrespro.ru> wrote:
Hi!On Wed, Jun 21, 2017 at 10:52 AM, Shubham Barai <shubhambaraiss@gmail.com> wrote:I took a look on this patch.Hi,
On 21 June 2017 at 13:11, Heikki Linnakangas <hlinnaka@iki.fi> wrote:I know that. This is the old version of the patch. I had sent updated patch later. Please have a look at updated patch.On 06/16/2017 01:24 PM, Shubham Barai wrote:@@ -497,6 +499,13 @@ gistplacetopage(Relation rel, Size freespace, GISTSTATE *giststate,
for (ptr = dist->next; ptr; ptr = ptr->next)
UnlockReleaseBuffer(ptr->buffer);
}
+
+ for (ptr = dist; ptr; ptr = ptr->next)
+ PredicateLockPageSplit(rel,
+ BufferGetBlockNumber(buffer),
+ BufferGetBlockNumber(ptr->buffer));
+
+
I think this new code needs to go before the UnlockReleaseBuffer() calls above. Calling BufferGetBlockNumber() on an already-released buffer is not cool.
- HeikkiIn gistdoinsert() you do CheckForSerializableConflictIn() only if page wasn't exclusively locked before (xlocked is false). However, page might be exclusively locked before. And in this case CheckForSerializableConflictInif (!xlocked)
{
LockBuffer(stack->buffer, GIST_UNLOCK);
LockBuffer(stack->buffer, GIST_EXCLUSIVE);
CheckForSerializableConflictIn(r, NULL, stack->buffer);
xlocked = true;() would be skipped. That happens very rarely (someone fixes incomplete split before we did), but nevertheless.
I agree with Andrey Borodin's view on locks. I am quoting his message
"if xlocked = true, page was already checked for conflict after setting exclusive lock on it's buffer. I still do not see any problem here..."
Regards,
Shubham
В списке pgsql-hackers по дате отправления: