| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Markus Wanner <markus(at)bluegap(dot)ch> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net> |
| Subject: | Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!) |
| Date: | 2010-09-07 07:06:20 |
| Message-ID: | 4C85E46C.5080307@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 06/09/10 20:24, Markus Wanner wrote:
> On 09/06/2010 06:27 PM, Heikki Linnakangas wrote:
>> + * It's important to reset the latch*before* checking if there's work to
>> + * do. Otherwise, if someone sets the latch between the check and the
>> + * ResetLatch call, you will miss it and Wait will block.
>
> Why doesn't WaitLatch() clear it? What's the use case for waiting for a
> latch and *not* wanting to reset it?
Setting a latch that's already set is very fast, so you want to keep it
set until the last moment. See the coding in walsender for example, it
goes to some lengths to avoid clearing the latch until it's very sure
there's no more work for it to do. That helps to keep the overhead in
backends committing transactions low. (no-one has tried to measure that
yet, though)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2010-09-07 07:10:19 | patch: tsearch - some memory diet |
| Previous Message | Heikki Linnakangas | 2010-09-07 07:01:51 | Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!) |