On 8/2/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
. It would also be better if we didn't emit a
separate WAL record for defraging a page, if we also prune it at the
same time. I'm not that worried about WAL usage in general, but that
seems simple enough to fix.
Ah I see. I shall
On 8/2/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
On 8/2/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Maybe a nicer
solution would be to have another version of ConditionalLockBuffer with
three different return values: didn't get lock, got exclusive lock, or
got cleanup lock.
On 8/2/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
Please see the attached version 11 of HOT patch
Thanks!
One wrinkle in the patch is how the ResultRelInfo-struct is passed to
heap_update, and on to heap_check_idxupdate, to check any indexed
columns have
On Wed, 2007-08-01 at 21:09 +0100, Heikki Linnakangas wrote:
In heap_page_prune_defrag, it would be better to do the test for
BufferIsLockedForCleanup right after acquiring the lock. The longer the
delay between those steps, the bigger the chances that someone pins the
page and starts to wait
On Wed, 2007-08-01 at 14:36 +0530, Pavan Deolasee wrote:
Please see the attached version 11 of HOT patch
The concept of marking the pruned tuples with LP_DELETE and
reusing such tuples for subsequent UPDATEs has been removed
and replaced with a simpler mechanism of repairing the page
On 8/1/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2007-08-01 at 14:36 +0530, Pavan Deolasee wrote:
BufferIsLockedForCleanup() should be named BufferIsAvilableForCleanup().
There is no cleanup mode, what we mean is that there is only one pin;
the comments say If we are lucky enough to
Pavan Deolasee wrote:
Please see the attached version 11 of HOT patch
Thanks!
One wrinkle in the patch is how the ResultRelInfo-struct is passed to
heap_update, and on to heap_check_idxupdate, to check any indexed
columns have changed. I think that's a modularity violation, heap_update
really