On 03/09/10 21:50, Tom Lane wrote:
Heikki Linnakangas<heikki.linnakan...@enterprisedb.com> writes:
On 03/09/10 21:16, Tom Lane wrote:
It's probably not too unreasonable to assume that pid_t assignment is
atomic. But I'm still thinking that we have bigger problems than that
if there are really cases where SetLatch can execute at approximately
the same time as a latch owner is coming or going.
I don't see how to avoid it. A walsender, or any process really, can
exit at any time. It can make the latch inaccessible to others before it
exits to minimize the window, but it's always going to be possible that
another process is just about to call SetLatch when you exit.
Well, in that case what we need to do is presume that the latch object
has a continuing existence but the owner/receiver can come and go.
I would suggest that InitLatch needs to initialize the object into a
valid but unowned state; there is *no* deinitialize operation; and
there are AcquireLatch and ReleaseLatch operations to become owner
or stop being owner.
I think we have just a terminology issue. What you're describing is
exactly how it works now, if you just s/InitLatch/AcquireLatch. At the
moment there's no need for an initialization function other than the
InitLatch/AcquireLatch that associates the latch with the current
process. I can add one for the sake of future-proofing, and to have
better-defined behavior for setting a latch that has not been owned by
anyone yet, but it's not strictly necessary.
We also need to define the semantics of SetLatch
on an unowned latch --- does this set a signal condition that will be
available to the next owner?
At the moment, no. Perhaps that would be useful, separating the Init and
Acquire operations is needed to make that sane.
--
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
