"Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com> writes:
> - Another problem with the current HOT patch is that it generates
> tuple level fragmentation while reusing LP_DELETEd items when
> the new tuple is of smaller size than the original one. Heikki
> supported using best-fit strategy to reduce the fragmentation
> and thats worth trying. But ISTM that we can also correct
> row-level defragmentation whenever we run out of free space
> and LP_DELETEd tuples while doing UPDATE. Since this does not
> require moving tuples around, we can do this by a simple EXCLUSIVE
> lock on the page.
You are mistaken. To move existing tuples requires
LockBufferForCleanup, the same as VACUUM needs; otherwise some other
backend might continue to access a tuple it found previously.
How much testing of this patch's concurrent behavior has been done?
I'm wondering if any other locking thinkos are in there ...
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2007-03-02 15:13:18|
|Subject: Re: UPSERT |
|Previous:||From: Gregory Stark||Date: 2007-03-02 15:06:52|
|Subject: Re: UPSERT|