From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: HOT patch - version 15 |
Date: | 2007-09-06 06:20:48 |
Message-ID: | 87wsv4tiv3.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> On 9/6/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
>> Ah, as I understand it you can't actually do the pruning then because the
>> executor holds references to source tuple on the page. In other words you
>> can never "get the vacuum lock" there because you already have the page
>> pinned yourself.
>
> I don't think executor holding a reference is a problem because when
> we check for vacuum lock, we have already pinned the page anyways.
But that's the point. Even though the pin-count is 1 and it may look like we
have the vacuum lock we really don't. The fact that the buffer was already
pinned by us means that there are already pointers around referencing tuples
on that page. If we move them around those pointers become garbage. In fact
Postgres avoids copying data if it can get by with a pointer at the original
tuple on disk so some of the pointers will be Datums pointing at individual
columns in the tuples in the page.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-09-06 10:05:49 | Re: HOT patch - version 15 |
Previous Message | Tom Lane | 2007-09-06 04:56:21 | Re: [PATCHES] Lazy xid assignment V4 |