From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: crash-safe visibility map, take three |
Date: | 2010-11-30 15:53:25 |
Message-ID: | 4CF51DF5.8060107@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30.11.2010 17:38, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> On 30.11.2010 06:57, Robert Haas wrote:
>>> I can't say I'm totally in love with any of these designs. Anyone
>>> else have any ideas, or any opinions about which one is best?
>
>> Well, the design I've been pondering goes like this:
>
> Wouldn't it be easier and more robust to just consider VM bit changes to
> be part of the WAL-logged actions? That would include updating LSNs on
> VM pages and flushing VM pages to disk during checkpoint based on their
> LSN values. All of these other schemes seem too complicated and not
> provably correct.
The vm bit can be set once all the tuples on the page become visible to
everyone. There is no WAL-logged action at that point we could piggyback on.
Clearing the bit is already handled like that - replay of heap
insert/update/delete records clear the visibility map bit.
> Of course, that'd mean doing the bit changes inside the critical
> sections for the related actions, so it's not a trivial change
> code-wise, but neither are these other ideas.
Yeah, I'm not terribly excited about any of these schemes. The "intent"
record seems like the simplest one, but even that is quite different
from the traditional WAL-logging we do that it makes me slightly nervous.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-11-30 15:54:50 | Re: crash-safe visibility map, take three |
Previous Message | Robert Haas | 2010-11-30 15:46:44 | Re: crash-safe visibility map, take three |