On 06/09/10 19:27, Heikki Linnakangas wrote:
On 06/09/10 17:18, Tom Lane wrote:
BTW, on reflection the AcquireLatch/ReleaseLatch terminology seems a bit
ill chosen: ReleaseLatch sounds way too much like something that would
just unlock or clear the latch. Perhaps OwnLatch/DisownLatch, or
something along that line.
Yeah, I see what you mean. Although, maybe it's just me but Own/Disown
looks ugly. Anyone have a better suggestion?
Magnus suggested AssociateLatch, given that the description of the
function is that it associates the latch with the current process. I
went with Own/Disown after all, it feels more precise, and having made
the changes it doesn't look that ugly to me anymore.
Here's an updated patch, with all the issues reported this far fixed,
except for that naming issue, and Fujii's suggestion to use poll()
instead of select() where available. I've also polished it quite a bit,
improving comments etc. Magnus, can you take a look at the Windows
implementation to check that it's sane? At least it seems to work.
We discussed the patch over IM, there's one point minor point I'd like
to get into the archives:
It seems that NumSharedLatches() is entirely wrongly placed if it's in
the win32 specific code! That needs to be somewhere shared, so people find it,
Yeah. There's a notice of that in OwnLatch(), but it would be nice if we
could make it even more prominent. One idea is to put in latch.h as:
#define NumSharedLatches() (max_wal_senders /* + something else in the
future */ )
When it's a #define, we don't need to put #include "walsender.h" in
latch.h, it's enough to put it in win32_latch.c. It's a bit weird to
have a #define in one header file that doesn't work unless you #include
another header file in where you use it, but it would work. Any opinions
on whether that's better than having NumSharedLatches() defined in the
Win32-specific win32_latch.c file? I'm inclined to leave it as it is, in
win32_latch.c, but I'm not sure.
Barring any last-minute objections, I'll commit this in the next few
days. This patch doesn't affect walreceiver yet; I think the next step
is to use the latches to eliminate the polling loop in walreceiver too,
so that as soon as a piece of WAL is fsync'd to disk in the standby,
it's applied.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
