Re: Reviewing freeze map code
От | Andres Freund |
---|---|
Тема | Re: Reviewing freeze map code |
Дата | |
Msg-id | 20160610063923.anzfsuwfupqw2pap@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Reviewing freeze map code (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Reviewing freeze map code
Re: Reviewing freeze map code |
Список | pgsql-hackers |
On 2016-06-10 11:58:26 +0530, Amit Kapila wrote: > I have tried in multiple ways by running pgbench with read-write tests, but > could not see any such behaviour. It took over an hour of pgbench on a fast laptop till I saw it. > I have tried by even crashing and > restarting the server and then again running pgbench. Do you see these > records on master or slave? Master, but with an existing standby. So it could be related to hot_standby_feedback or such. > While looking at code in this area, I observed that during replay of > records (heap_xlog_delete), we first clear the vm, then update the page. > So we don't have Buffer lock while updating the vm where as in the patch > (collect_corrupt_items()), we are relying on the fact that for clearing vm > bit one needs to acquire buffer lock. Can that cause a problem? Unsetting a vm bit is always safe, right? The invariant is that the VM may never falsely say all_visible/frozen, but it's perfectly ok for a page to be all_visible/frozen, without the VM bit being present. Andres
В списке pgsql-hackers по дате отправления: