Re: WALInsertLock tuning
От | Simon Riggs |
---|---|
Тема | Re: WALInsertLock tuning |
Дата | |
Msg-id | BANLkTinEdR76-Ps0Dw_XqX_X90ELUh-Niw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WALInsertLock tuning (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WALInsertLock tuning
(Jeff Janes <jeff.janes@gmail.com>)
|
Список | pgsql-hackers |
On Mon, Jun 6, 2011 at 5:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> In earlier discussions of how to improve WALInsertLock contention, it >> was observed that we must zero each new page before we advance the WAL >> insertion point. >> http://postgresql.1045698.n5.nabble.com/Reworking-WAL-locking-td1983647.html > >> IMHO the page zeroing is completely unnecessary, > > I don't believe it's "completely unnecessary". It does in fact offer > additional protection against mistakenly taking stale data as valid. > You could maybe argue that the degree of safety increase isn't > sufficient to warrant the cost of zeroing the page, but you've not > offered any quantification of either the risk or the cost savings. If we did ever reference stale data, it would need to have a value of xl_prev that exactly matched what we expected AND would also need a CRC that exactly matched also. That would be fairly difficult to arrange deliberately and pretty close to zero chance of happening otherwise. But that even assumes we write the unzeroed data at the end of the buffer. We don't. We only write data up to the end of the WAL record on the current page, unless we do a continuation record, which means only replay we would read in another page and check page headers. So for this to cause an error, we'd have to have an overall matching CRC, a matching xl_prev and at least one matching page header, which contains a pageaddress. But that even assumes we would read data in a different way to which it was written. So the only way we could ever reference the stale data is if the WAL reading code didn't match the WAL writing code (1) because of a bug or (2) because of a corrupt pg_control record that caused random access to an otherwise unreachable part of WAL AND the CRC matched, and the xl_prev matched and the next page header matched. Risk == zero. If it wasn't zero I would even mention it because this is not a trade-off optimization. Cost savings are those already identified by yourself in our previous discussion on this, link given upthread. It's the biggest single removable item from within WALInsertLock. We can measure them if you like, but I don't see the value in that. It will clearly be a useful saving on what we all agree is a heavily contended lock. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: