On Sat, Nov 20, 2010 at 4:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> So what DO we need to guard against here?
>
> I think the general problem can be stated as "process A changes two or
> more values in shared memory in a fairly short span of time, and process
> B, which is concurrently examining the same variables, sees those
> changes occur in a different order than A thought it made them in".
>
> In practice we do not need to worry about changes made with a kernel
> call in between, as any sort of context swap will cause the kernel to
> force cache synchronization.
>
> Also, the intention is that the locking primitives will take care of
> this for any shared structures that are protected by a lock. (There
> were some comments upthread suggesting maybe our lock code is not
> bulletproof; but if so that's something to fix in the lock code, not
> a logic error in code using the locks.)
>
> So what this boils down to is being an issue for shared data structures
> that we access without using locks. As, for example, the latch
> structures.
So is the problem case a race involving owning/disowning a latch vs.
setting that same latch?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company