On Sat, Nov 20, 2010 at 4:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers