Re: cheaper snapshots
От | Hannu Krosing |
---|---|
Тема | Re: cheaper snapshots |
Дата | |
Msg-id | 1311865828.3117.1425.camel@hvost обсуждение исходный текст |
Ответ на | Re: cheaper snapshots (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: cheaper snapshots
Re: cheaper snapshots |
Список | pgsql-hackers |
On Thu, 2011-07-28 at 10:45 -0400, Tom Lane wrote: > Hannu Krosing <hannu@2ndQuadrant.com> writes: > > On Thu, 2011-07-28 at 10:23 -0400, Robert Haas wrote: > >> I'm confused by this, because I don't think any of this can be done > >> when we insert the commit record into the WAL stream. > > > The update to stored snapshot needs to happen at the moment when the WAL > > record is considered to be "on stable storage", so the "current > > snapshot" update presumably can be done by the same process which forces > > it to stable storage, with the same contention pattern that applies to > > writing WAL records, no ? > > No. There is no reason to tie this to fsyncing WAL. For purposes of > other currently-running transactions, the commit can be considered to > occur at the instant the commit record is inserted into WAL buffers. > If we crash before that makes it to disk, no problem, because nothing > those other transactions did will have made it to disk either. Agreed. Actually figured it out right after pushing send :) > The > advantage of defining it that way is you don't have weirdly different > behaviors for sync and async transactions. My main point was, that we already do synchronization when writing wal, why not piggyback on this to also update latest snapshot . -- ------- Hannu Krosing PostgreSQL (Infinite) Scalability and Performance Consultant PG Admin Book: http://www.2ndQuadrant.com/books/
В списке pgsql-hackers по дате отправления: