| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Daniel Farina <daniel(at)heroku(dot)com> |
| Subject: | Re: Sync Rep v17 |
| Date: | 2011-03-01 15:15:53 |
| Message-ID: | 16564.1298992553@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Mar 1, 2011 at 3:21 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> LWlocks are just spinlocks plus sem sleeps, so I don't see the need for
>> that in the current code. Other views welcome.
> An LWLock is a lot safer, in general, than a spinlock. A spinlock
> mustn't do anything that could emit an error or abort (among other
> things). I doubt that the performance cost of using an LWLock rather
> than a spin lock here is enough to matter, and the spin lock seems
> more likely to result in hard-to-find bugs.
Well, stuck spinlocks aren't exactly hard to identify. But I agree that
the lack of any release-on-error infrastructure is a killer reason not
to use a spinlock for anything but short straight-line code segments.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | hom | 2011-03-01 15:15:58 | error order when debug postgresql step by step? |
| Previous Message | Heikki Linnakangas | 2011-03-01 15:11:38 | Re: PG signal handler and non-reentrant malloc/free calls |