Re: Moving more work outside WALInsertLock
От | Simon Riggs |
---|---|
Тема | Re: Moving more work outside WALInsertLock |
Дата | |
Msg-id | CA+U5nMKyTz5r5taMCAGLVhx79ShdRfwLjsLe5xgQhVpk8dtwpA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Moving more work outside WALInsertLock (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Moving more work outside WALInsertLock
|
Список | pgsql-hackers |
On Thu, Dec 15, 2011 at 6:50 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: >> unless you are proposing to remove >> the prev_link from the scope of the CRC, which is not exactly a >> penalty-free change. > > > We could CRC the rest of the record header before getting the lock, though, > and only include the prev-link while holding the lock. I micro-benchmarked > that a little bit, but didn't see much benefit from doing just that. Once > you do more drastic changes so that the lock doesn't need to be held while > copying the data and calculating the CRC of the record header, so that those > things can be done in parallel, it matters even less. You missed your cue to discuss leaving the prev link out of the CRC altogether. On its own that sounds dangerous, but its not. When we need to confirm the prev link we already know what we expect it to be, so CRC-ing it is overkill. That isn't true of any other part of the WAL record, so the prev link is the only thing we can relax, but thats OK because we can CRC check everything else outside of the locked section. That isn't my idea, but I'm happy to put it on the table since I'm not shy. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: