Re: sinval synchronization considered harmful - Mailing list pgsql-hackers

From Robert Haas
Subject Re: sinval synchronization considered harmful
Date
Msg-id CA+TgmobefJvyQDjVBb6TSs996s8ZKvyRzTtPx0ChYo3hve52tg@mail.gmail.com
Whole thread Raw
In response to Re: sinval synchronization considered harmful  (Noah Misch <noah@2ndQuadrant.com>)
Responses Re: sinval synchronization considered harmful
Re: sinval synchronization considered harmful
List pgsql-hackers
On Tue, Jul 26, 2011 at 4:38 PM, Noah Misch <noah@2ndquadrant.com> wrote:
> No new ideas come to mind, here.

OK, I have a new idea.  :-)

1. Add a new flag to each procState called something like "timeToPayAttention".
2. Each call to SIGetDataEntries() iterates over all the ProcStates
whose index is < lastBackend and sets stateP->timeToPayAttention =
TRUE for each.
3. At the beginning of SIGetDataEntries(), we do an unlocked if
(!stateP->timeToPayAttention) return 0.
4. Immediately following that if statement and before acquiring any
locks, we set stateP->timeToPayAttention = FALSE.

The LWLockRelease() in SIGetDataEntries() will be sufficient to force
all of the stateP->timeToPayAttention writes out to main memory, and
the read side is OK because we either just took a lock (which acted as
a fence) or else there's a race anyway.  But unlike my previous
proposal, it doesn't involve *comparing* anything.  We needn't worry
about whether we could read two different values that are through
great misfortune out of sync because we're only reading one value.

If, by chance, the value is set to true just after we set it to false,
that won't mess us up either: we'll still read all the messages after
acquiring the lock.

Now, there's some downside to this approach - it involves doing O(N)
work for each invalidation message we receive.  But as long as it's
only O(N) stores and not O(N) lock acquisitions and releases, I think
that might be OK.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: sinval synchronization considered harmful
Next
From: Noah Misch
Date:
Subject: Re: sinval synchronization considered harmful