Re: SSI implementation question
От | Kevin Grittner |
---|---|
Тема | Re: SSI implementation question |
Дата | |
Msg-id | 4E9F02850200002500042271@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: SSI implementation question (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SSI implementation question
|
Список | 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 по дате отправления: