Re: Hot standby, conflict resolution - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Hot standby, conflict resolution
Date
Msg-id 497DEF7B.6050904@enterprisedb.com
Whole thread Raw
In response to Re: Hot standby, conflict resolution  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs wrote:
> Rather than signalling, we could use a hasconflict boolean for each proc
> in a shared data structure. It can be read without spinlock, but should
> only be written while holding spinlock.
> 
> Each time we read a block we check if hasconflict is set. If it is, we
> grab spinlock, recheck if it is set, if so read the conflict details,
> clear the flag and drop the spinlock.

Yeah, that seems workable.

> The aim of this type of conflict resolution was to reduce the footprint
> of users that would be effected and defer it as much as possible. We've
> spent time getting the latestCompletedXid, but we know deriving that
> value is very difficult in the btree case at least. So what I would like
> to do is pass the relid of a conflict across as well and use that to
> reduce the footprint, now that we are performing the test inside the
> buffer manager.

I agree that would be useful, but I'd prefer to keep it simple for now...

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: 8.4 release planning
Next
From: KaiGai Kohei
Date:
Subject: Re: 8.4 release planning