"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
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> 2) GUC_DISALLOW_IN_FILE flag is ignored during configuration file parsing.
Yeah, that's not enforced at the moment, it's just documentation.
Most of the variables that are marked that way have other defenses
against being changed from the file, so I'm no
Joachim Wieland wrote:
Still it does not what I think it should do. I might have been unclear
before. If you put a comment in front of a PGC_POSTMASTER variable (and if
its value differs from the default) then this should be treated as if the
variable got changed and it should emmit a warning "
