Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> Dan Ports <d...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
