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  (Dan Ports <drkp@csail.mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: SSI implementation question
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces