From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: HOT synced with HEAD |
Date: | 2007-09-17 07:32:43 |
Message-ID: | 2e78013d0709170032u64b0c898sf2b7ad386fb661d8@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On 9/17/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>
> Yeah. As the code stands, anything that's XMIN_INVALID will be
> considered not-HotUpdated (look at the macro...). So far I've seen no
> place where there is any value in following a HOT chain past such a
> tuple --- do you see any?
>
No, I don't think we would ever need to follow a HOT chain past
the aborted tuple. The only thing that worries about this setup though
is the dependency on hint bits being set properly. But the places
where this would be used right now for detecting aborted dead tuples,
apply HeapTupleSatisfiesVacuum on the tuple before checking
for HeapTupleIsHotUpdated, so we are fine. Or should we just check
for XMIN_INVALID explicitly at those places ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-09-17 13:32:14 | Re: [COMMITTERS] pgsql: Avoid possibly-unportable initializer, per buildfarm warning. |
Previous Message | Tom Lane | 2007-09-17 04:02:47 | Re: invalidly encoded strings |