| From: | Markus Wanner <markus(at)bluegap(dot)ch> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Deadlock bug |
| Date: | 2010-08-25 15:30:07 |
| Message-ID: | 4C7536FF.5010700@bluegap.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
do exist?
Regards
Markus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2010-08-25 15:31:59 | Re: initdb fails to allocate shared memory |
| Previous Message | A.M. | 2010-08-25 15:15:21 | initdb fails to allocate shared memory |