Ühel kenal päeval, E, 2006-09-04 kell 16:51, kirjutas Joshua D. Drake:
> > I don't have a concrete proposal to make, but I do think that the
> > current patch-queue process is not suited to the project as it stands
> > today. Maybe if this issue-tracking stuff gets off the ground, we
> > could let
Gavin Sherry wrote:
On Mon, 4 Sep 2006, Joshua D. Drake wrote:
I don't have a concrete proposal to make, but I do think that the
current patch-queue process is not suited to the project as it stands
today. Maybe if this issue-tracking stuff gets off the ground, we
could let developers place AC
On Mon, 4 Sep 2006, Joshua D. Drake wrote:
>
> > I don't have a concrete proposal to make, but I do think that the
> > current patch-queue process is not suited to the project as it stands
> > today. Maybe if this issue-tracking stuff gets off the ground, we
> > could let developers place ACK or
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> How about *requiring* test cases that prove the patch?
There are lots and lots of things that can't really be tested with
pg_regress-based tests, and in any case a test does not prove the
absence of bugs; particularly not a test devised by the code a
Joshua D. Drake wrote:
>
> > I don't have a concrete proposal to make, but I do think that the
> > current patch-queue process is not suited to the project as it stands
> > today. Maybe if this issue-tracking stuff gets off the ground, we
> > could let developers place ACK or NAK flags on patches
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> This rush to apply patches just because no one seems to be capable of
> >> keeping up with them not being reviewed, is starting to get a bit
> >> worrisome.
>
> > When things are placed in the patches queue,
I don't have a concrete proposal to make, but I do think that the
current patch-queue process is not suited to the project as it stands
today. Maybe if this issue-tracking stuff gets off the ground, we
could let developers place ACK or NAK flags on patches they've looked
at, and have some rule
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> This rush to apply patches just because no one seems to be capable of
>> keeping up with them not being reviewed, is starting to get a bit
>> worrisome.
> When things are placed in the patches queue, I need to get feedback if
> t
Alvaro Herrera wrote:
> > > I see the no-index case now:
> > >
> > > + if (nindexes)
> > > + LockBuffer(buf, BUFFER_LOCK_SHARE);
> > > + else
> > > + LockBufferForCleanup(buf);
> > >
> > > Let's see what Greg says, or revert.
>
Gregory Stark wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> > Patch applied. Thanks.
> >>
> >> Wait a minute. This patch changes the behavior so that
> >> LockBufferForCleanup is applied to *every* heap page, not
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> > Patch applied. Thanks.
>>
>> Wait a minute. This patch changes the behavior so that
>> LockBufferForCleanup is applied to *every* heap page, not only the ones
>> where there are remov
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Patch applied. Thanks.
>
> Wait a minute. This patch changes the behavior so that
> LockBufferForCleanup is applied to *every* heap page, not only the ones
> where there are removable tuples. It's not hard to imagine scenarios
> w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Patch applied. Thanks.
Wait a minute. This patch changes the behavior so that
LockBufferForCleanup is applied to *every* heap page, not only the ones
where there are removable tuples. It's not hard to imagine scenarios
where that results in severe sy
Patch applied. Thanks.
---
Gregory Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > The reason the patch is so short is that it's a kluge. If we really
> > cared about supporting this case, more wide-ranging
Gregory Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > The reason the patch is so short is that it's a kluge. If we really
> > cared about supporting this case, more wide-ranging changes would be
> > needed (eg, there's no need to eat maintenance_work_mem worth of RAM
> > for the de
Tom Lane <[EMAIL PROTECTED]> writes:
> The reason the patch is so short is that it's a kluge. If we really
> cared about supporting this case, more wide-ranging changes would be
> needed (eg, there's no need to eat maintenance_work_mem worth of RAM
> for the dead-TIDs array); and a decent respec
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> How often does that case come up in the real world, for tables that are
>> large enough that you'd care about vacuum performance?
> I would have had the same objection if it resulted in substantially more
> complex
Tom Lane <[EMAIL PROTECTED]> writes:
> stark <[EMAIL PROTECTED]> writes:
>> There isn't really any need for the second pass in lazy vacuum if the table
>> has no indexes.
>
> How often does that case come up in the real world, for tables that are
> large enough that you'd care about vacuum perfor
stark <[EMAIL PROTECTED]> writes:
> There isn't really any need for the second pass in lazy vacuum if the table
> has no indexes.
How often does that case come up in the real world, for tables that are
large enough that you'd care about vacuum performance?
regards, tom lan
19 matches
Mail list logo
