| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexey Klyukin <alexk(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Reducing overhead of frequent table locks |
| Date: | 2011-05-27 21:50:36 |
| Message-ID: | 20110527215036.GA7188@tornado.gateway.2wire.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 27, 2011 at 04:55:07PM -0400, Robert Haas wrote:
> When a strong lock is taken or released, we have to increment or
> decrement strong_lock_counts[fasthashpartition]. Here's the question:
> is that atomic? In other words, suppose that strong_lock_counts[42]
> starts out at 0, and two backends both do ++strong_lock_counts[42].
> Are we guaranteed to end up with "2" in that memory location or might
> we unluckily end up with "1"? I think the latter is possible... and
> some guard is needed to make sure that doesn't happen.
Yeah: what Tom said. Guard it with a spinlock? Given that the backend is about
to (or did earlier) go off and acquire dozens or hundreds of LWLocks, it doesn't
seem like an area begging for early optimization.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2011-05-27 21:54:35 | Re: How can I check the treatment of bug fixes? |
| Previous Message | Fabien COELHO | 2011-05-27 21:48:06 | Re: minor patch submission: CREATE CAST ... AS EXPLICIT |