On Wed, Jan 30, 2013 at 11:37:41PM +0530, Pavan Deolasee wrote:
On Wed, Jan 30, 2013 at 7:34 AM, Noah Misch n...@leadboat.com wrote:
On Mon, Jan 28, 2013 at 07:24:04PM +0530, Pavan Deolasee wrote:
On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch n...@leadboat.com wrote:
You're the second
On Wed, Jan 30, 2013 at 7:34 AM, Noah Misch n...@leadboat.com wrote:
On Mon, Jan 28, 2013 at 07:24:04PM +0530, Pavan Deolasee wrote:
On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch n...@leadboat.com wrote:
You're the second commentator to be skittish about the patch's
correctness, so
I
On Mon, Jan 28, 2013 at 07:24:04PM +0530, Pavan Deolasee wrote:
On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch n...@leadboat.com wrote:
You're the second commentator to be skittish about the patch's correctness,
so
I won't argue against a conservatism-motivated bounce of the patch.
Can
On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch n...@leadboat.com wrote:
You're the second commentator to be skittish about the patch's correctness, so
I won't argue against a conservatism-motivated bounce of the patch.
Can you please rebase the patch against the latest head ? I see
Alvaro's and
On 23 January 2013 04:35, Noah Misch n...@leadboat.com wrote:
Also, perhaps we should
consider Simon's one-liner fix for backpatching this instead of the
original patch you posted?
I have no nontrivial preference between the two approaches.
Sorry, I didn't see this. I guess you saw I
On Mon, Jan 28, 2013 at 02:12:33PM +, Simon Riggs wrote:
On 23 January 2013 04:35, Noah Misch n...@leadboat.com wrote:
Also, perhaps we should
consider Simon's one-liner fix for backpatching this instead of the
original patch you posted?
I have no nontrivial preference between the
Noah,
* Noah Misch (n...@leadboat.com) wrote:
The attached update fixes both
problems. (I have also attached the unchanged backpatch-oriented fix to keep
things together.)
I've just started looking at/playing with this patch and was wondering
if you'd missed Jeff's comments on it..? I note
On Sat, Jan 19, 2013 at 02:58:32PM -0800, Jeff Janes wrote:
I have a preliminary nit-pick on the big patch. It generates a compiler
warning:
vacuumlazy.c: In function ?lazy_scan_heap?:
vacuumlazy.c:445:9: warning: variable ?prev_dead_count? set but not used
[-Wunused-but-set-variable]
On Tue, Jan 22, 2013 at 09:45:37PM -0500, Stephen Frost wrote:
* Noah Misch (n...@leadboat.com) wrote:
The attached update fixes both
problems. (I have also attached the unchanged backpatch-oriented fix to
keep
things together.)
I've just started looking at/playing with this patch
On Wednesday, January 9, 2013, Noah Misch wrote:
On Thu, Jan 10, 2013 at 02:45:36AM +, Simon Riggs wrote:
On 8 January 2013 02:49, Noah Misch n...@leadboat.com javascript:;
wrote:
There is a bug in lazy_scan_heap()'s
bookkeeping for the xid to place in that WAL record. Each call to
Hi Pavan,
Thanks for reviewing.
On Tue, Jan 08, 2013 at 02:41:54PM +0530, Pavan Deolasee wrote:
On Tue, Jan 8, 2013 at 8:19 AM, Noah Misch n...@leadboat.com wrote:
At that point in the investigation, I realized that the cost of being able
to
remove entire tuples in lazy_vacuum_heap()
On 8 January 2013 02:49, Noah Misch n...@leadboat.com wrote:
There is a bug in lazy_scan_heap()'s
bookkeeping for the xid to place in that WAL record. Each call to
heap_page_prune() simply overwrites vacrelstats-latestRemovedXid, but
lazy_scan_heap() expects it to only ever increase the
On Thu, Jan 10, 2013 at 02:45:36AM +, Simon Riggs wrote:
On 8 January 2013 02:49, Noah Misch n...@leadboat.com wrote:
There is a bug in lazy_scan_heap()'s
bookkeeping for the xid to place in that WAL record. Each call to
heap_page_prune() simply overwrites vacrelstats-latestRemovedXid,
On Tue, Jan 8, 2013 at 8:19 AM, Noah Misch n...@leadboat.com wrote:
At that point in the investigation, I realized that the cost of being able
to
remove entire tuples in lazy_vacuum_heap() greatly exceeds the benefit.
Again, the benefit is being able to remove tuples whose inserting
Per this comment in lazy_scan_heap(), almost all tuple removal these days
happens in heap_page_prune():
case HEAPTUPLE_DEAD:
/*
* Ordinarily, DEAD tuples would have
been removed by
15 matches
Mail list logo
