Manfred Koizar <[EMAIL PROTECTED]> writes:
> On Fri, 9 Jul 2004 21:29:52 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>>
>> Where are we on this, 2x. :-)
> Here:
> Tom Lane wrote:
> Will study these comments later, but it's too late at night here...
I haven't had time to review the o
[Sorry for the late reply. I'm still struggling to catch up after
vacation ...]
On Fri, 9 Jul 2004 21:29:52 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
>Where are we on this, 2x. :-)
Here:
>> Tom Lane wrote:
>> > Will study these comments later, but it's too late at night here...
S
Where are we on this, 2x. :-)
---
Bruce Momjian wrote:
>
> Where are we on this?
>
> ---
>
> Tom Lane wrote:
> > Manfred Koizar <[EMAIL PROTECTED]>
Where are we on this?
---
Tom Lane wrote:
> Manfred Koizar <[EMAIL PROTECTED]> writes:
> > I understand you, honestly. Do I read between your lines that you
> > didn't review my previous vacuum.c refactoring patch? Please
"Dann Corbit" <[EMAIL PROTECTED]> writes:
>> It was done and we fixed a couple of bugs based on it (the
>> one I can think of offhand had to do with semantics of
>> aggregate functions in sub-selects). I don't think there's
>> anything more to be learned there.
> It is reassuring to know that
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 11, 2004 2:35 PM
> To: Dann Corbit
> Cc: Manfred Koizar; [EMAIL PROTECTED]
> Subject: Re: TESTING (was: RE: [HACKERS] More vacuum.c refactoring )
>
>
> "Dann Co
"Dann Corbit" <[EMAIL PROTECTED]> writes:
>> --- and no I have zero confidence that passing the regression
>> tests proves anything, because all those prior bugs passed
>> the regression tests.
> Then why didn't those bugs get added to the regression?
Because there wasn't any reasonable way to
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: Thursday, June 10, 2004 2:19 PM
> To: Manfred Koizar
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] More vacuum.c refactoring
>
>
> Manfred Koi
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Maybe we could establish heavier testing for this kind of change so
> potential patches can be tested extensively. Concurrent vacuums with
> all kinds of imaginable operations (insert, updates, deletes), in tight
> loops, could be a start.
VACUUM FULL
Manfred Koizar <[EMAIL PROTECTED]> writes:
> I understand you, honestly. Do I read between your lines that you
> didn't review my previous vacuum.c refactoring patch? Please do. It'd
> make *me* more comfortable.
I did not yet, but I will get to it. I encourage everyone else to
take a look too
On Fri, Jun 11, 2004 at 02:00:07AM +0200, Manfred Koizar wrote:
If I may ...
> > so you want to hack up vacuum.c? This
> >module is delicate code --- we've had tons of bugs there in the past
>
> But why is it so delicate? Not only because it handles difficult
> problems, but also because it is
On Thu, 10 Jun 2004 17:19:22 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>This does not make me comfortable.
I understand you, honestly. Do I read between your lines that you
didn't review my previous vacuum.c refactoring patch? Please do. It'd
make *me* more comfortable.
> You *think* that tw
Manfred Koizar <[EMAIL PROTECTED]> writes:
> This code is very similar to vacuum_page(). The major difference is
> that vacuum_page() uses vacpage->offsets while the code in repair_frag()
> looks for MOVED_OFF bits in tuple headers. AFAICS the tuples with the
> MOVED_OFF bit set are exactly those
Near the end of repair_frag() in vacuum.c -- under the comment /* clean
moved tuples from last page in Nvacpagelist list */ -- there is code
that marks itemids as unused. Itemids affected are those referring to
tuples that have been moved off the last page.
This code is very similar to vacuum_pag
14 matches
Mail list logo
