On Wed, Jan 30, 2013 at 11:37:41PM +0530, Pavan Deolasee wrote:
> On Wed, Jan 30, 2013 at 7:34 AM, Noah Misch 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 wrote:
> >>
> >> > You're the second commentator to be skittis
On Wed, Jan 30, 2013 at 7:34 AM, Noah Misch 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 wrote:
>>
>> > You're the second commentator to be skittish about the patch's
>> > correctness, so
>> > I won't argue against a con
On Mon, Jan 28, 2013 at 07:24:04PM +0530, Pavan Deolasee wrote:
> On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch 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 plea
On Mon, Jan 28, 2013 at 02:12:33PM +, Simon Riggs wrote:
> On 23 January 2013 04:35, Noah Misch 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 a
On 23 January 2013 04:35, Noah Misch 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 applied my one l
On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch 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 Simon's recent c
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 thi
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]
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 not
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 >
> 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_pru
On Thu, Jan 10, 2013 at 02:45:36AM +, Simon Riggs wrote:
> On 8 January 2013 02:49, Noah Misch 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
> > l
On 8 January 2013 02:49, Noah Misch 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 value. I have a
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 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
On Tue, Jan 8, 2013 at 8:19 AM, Noah Misch 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
> transaction
> abort
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
