| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
| Cc: | josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Frequent Update Project: Design Overview of HOT Updates |
| Date: | 2006-11-10 05:27:48 |
| Message-ID: | 16166.1163136468@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> On 11/10/06, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> I believe that's the "unsolved technical issue" in the prototype, unless
>> Pavan has solved it in the last two weeks. Pavan?
>>
> When an overflow tuple is copied back to the main heap, the overflow tuple
> is
> marked with a special flag (HEAP_OVERFLOW_MOVEDBACK). Subsequently,
> when a backend tries to lock the overflow version of the tuple, it checks
> the flag
> and jumps to the main heap if the flag is set.
(1) How does it "jump to the main heap"? The links go the other
direction.
(2) Isn't this full of race conditions?
(3) I thought you already used up the one remaining t_infomask bit.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2006-11-10 06:23:28 | Re: Frequent Update Project: Design Overview of HOT Updates |
| Previous Message | Pavan Deolasee | 2006-11-10 02:24:28 | Re: Frequent Update Project: Design Overview of HOT Updates |