Re: [COMMITTERS] pgsql: Make the visibility map crash-safe.
| От | Robert Haas |
|---|---|
| Тема | Re: [COMMITTERS] pgsql: Make the visibility map crash-safe. |
| Дата | |
| Msg-id | BANLkTi=gfQodjQGRxPUOcHon=dvW=LZ76Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [COMMITTERS] pgsql: Make the visibility map crash-safe. (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [COMMITTERS] pgsql: Make the visibility map crash-safe.
|
| Список | pgsql-hackers |
On Wed, Jun 22, 2011 at 9:12 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Jun 22, 2011 at 6:55 AM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >> On 22.06.2011 06:05, Robert Haas wrote: >>> >>> Second, when inserting, updating, or deleting >>> a tuple, we can no longer get away with clearing the visibility map >>> bit after releasing the lock on the corresponding heap page, because >>> an intervening crash might leave the visibility map bit set and the >>> page-level bit clear. >> >> heap_update seems to still do that. > > Aw, crap. I'll take another look. Well, it seems I didn't put nearly enough thought into heap_update(). The fix for the immediate problem looks simple enough - all the code has been refactored to use the new API, so the calls can be easily be moved into the critical section (see attached). But looking at this a little more, I see that heap_update() is many bricks short of a load, because there are several places where the buffer can be unlocked and relocked, and we don't recheck whether the page is all-visible after reacquiring the lock. So I've got some more work to do here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: