From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: remove lock protection on HeapTupleSatisfiesVacuum |
Date: | 2006-06-06 03:21:55 |
Message-ID: | 9878.1149564115@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> Attached is a patch to remove the lock protection for
> HeapTupleSatisfiesVacuum() in index code.
This patch scares the heck out of me. You need to offer some pretty
compelling performance reasons before I'd accept any part of it,
most especially this:
*** bufmgr.c 14 Apr 2006 03:38:55 -0000 1.207
--- bufmgr.c 6 Jun 2006 02:07:09 -0000
***************
*** 1686,1693 ****
bufHdr = &BufferDescriptors[buffer - 1];
Assert(PrivateRefCount[buffer - 1] > 0);
- /* here, either share or exclusive lock is OK */
- Assert(LWLockHeldByMe(bufHdr->content_lock));
/*
* This routine might get called many times on the same page, if we are
--- 1686,1691 ----
Changing a buffer you hold no lock on is a recipe for disaster.
Where is the performance-boost evidence that suggests we should
even take the time to analyze whether this is safe?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2006-06-06 04:32:06 | Re: remove lock protection on HeapTupleSatisfiesVacuum |
Previous Message | Tom Lane | 2006-06-06 03:08:37 | Re: fillfactor using WITH syntax |