Re: SSI implementation question - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: SSI implementation question
Date
Msg-id 4E9F02850200002500042271@gw.wicourts.gov
Whole thread Raw
In response to Re: SSI implementation question  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SSI implementation question
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Dan Ports <drkp@csail.mit.edu> wrote:
>>> the sxact's lastCommitBeforeSnapshot needs to match the
>>> snapshot, SxactGlobalXmin needs to be set to the correct value,
>>> etc. That's why the call to GetSnapshotData happens from where
>>> it does
>  
>> Oh, right.  I knew I was forgetting something.  What if that was
>> captured as part of building a snapshot?  That seems like it
>> would be a trivial cost compared to other snapshot-building
>> activity, and might give us a way to get this out from under the
>> SerializableXactHashLock locking.
> 
> But aren't the values you need to fetch protected by
> SerializableXactHashLock?  Having to take an additional LWLock is
> *not* a "trivial cost".
I was thinking that this would become a more general "commit
sequence number" and could be bundled into the snapshot.  It would
also allow cleaning up the funny double-increment we did as a
workaround for this not being incremented at the actual moment of
commit.  There was actually a patch floated to do it that way near
the end of the 9.1 development cycle.  I imagine that's probably
suffered major bitrot because of Robert's 9.2 work, but the general
idea is the same.
I agree that if it can't fit under existing locks at commit and
snapshot build times, it isn't feasible.
-Kevin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SSI implementation question
Next
From: Tom Lane
Date:
Subject: Re: pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces