On 08/25/2010 04:57 PM, Tom Lane wrote:
> It strikes me that a possibly useful simplification of the idea is a
> lock type that allows HOT updates and not non-HOT ones; or more
> precisely not ones that change any indexed columns --- if the row ends
> up having to go off-page for lack of space, that need not concern us.
Nice idea. And as Simon puts it, it probably covers most use cases.
So called "hot locks" ;-)
OTOH, if it doesn't cover HOT exactly (i.e. the go off-page case), it
probably shouldn't be called that. And for helping in the OPs case, it
would suffice to let the lock protect against changes to any attributes
that are covered by a UNIQUEness constraint.
So, the question probably is, what other use cases for such a lock type
In response to
pgsql-hackers by date
|Next:||From: Joshua D. Drake||Date: 2010-08-25 15:31:59|
|Subject: Re: initdb fails to allocate shared memory|
|Previous:||From: A.M.||Date: 2010-08-25 15:15:21|
|Subject: initdb fails to allocate shared memory|