Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Dan Ports <drkp(at)csail(dot)mit(dot)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