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. 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? This amount of complexity might be overkill for local latches, but I think we need it for shared ones. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers