""Jim C. Nasby"" <[EMAIL PROTECTED]> wrote
>
> Maybe a comment patch would be in order to prevent future confusion?
>
Not really needed because the buffer/README access rule#1 has already said
that ...
Regards,
Qingqing
---(end of broadcast)---
On Wed, Jun 07, 2006 at 09:34:47AM +0800, Qingqing Zhou wrote:
>
> "Qingqing Zhou" <[EMAIL PROTECTED]> wrote
> >
> > The overall performance improvement might be marginal but why not if it is
> > right. What I cares is the correctness. As I understand, the orginal code
> > puts a shared lock (1) t
"Qingqing Zhou" <[EMAIL PROTECTED]> wrote
>
> The overall performance improvement might be marginal but why not if it is
> right. What I cares is the correctness. As I understand, the orginal code
> puts a shared lock (1) to prevent the vacuum process to move tuples around
> so the hint bits chang
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> 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,
> Changing a buffer you hold no lock on is a recipe for disaster.
>
Me too, in fact :-(.
The overall performance improve
Qingqing Zhou <[EMAIL PROTECTED]> 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:
Attached is a patch to remove the lock protection for
HeapTupleSatisfiesVacuum() in index code. The basic idea is: if we can do
a pin/lock/unlock sequence on a page, then without locking again, we are
gauranteed that there is no vacuum process acting on the same page.
According to buffer pool acc
