From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Visibility map thoughts |
Date: | 2007-11-06 13:52:58 |
Message-ID: | 473071BA.30407@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>
>> One problem is that you have to atomically update the visibility map when
>> you update the heap. That means that you have to lock the visibility map
>> page and the heap page at the same time. If the visibility map is in the
>> heap, you need to take care that you don't deadlock.
>
> Well that's still a problem if it's in another filenode.
>
> On the other hand if you allocate a whole byte to every page you could set it
> atomically and not have to lock the page. Effectively having the lock on the
> original page protect the info byte. Whereas setting a single bit requires
> protecting against someone setting one of the other bits corresponding to
> another page entirely.
I don't buy that. I believe at least on some architectures you'd get a
word-long load+modify+store, and scribble the neighboring bytes.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-11-06 14:08:37 | Re: Visibility map thoughts |
Previous Message | Marko Kreen | 2007-11-06 13:40:22 | Re: Visibility map thoughts |