Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 06/09/10 19:27, Heikki Linnakangas wrote:
>> 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.
We have other precedents for that. But having said that ...
> 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.
I'd leave it alone. I see no very good reason to expose
NumSharedLatches globally.
> 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.
I will do some work as well once it's in. Since I was the one
complaining about extra wakeups in the other processes, I'm willing
to go fix 'em.
regards, tom lane