Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Knew I should have taken time to review that patch before it went in ...
> Which one? The one I applied doesn't have this change.
Never mind --- I misunderstood the context of the discussion and thought
you had made larger changes i
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Ãhel kenal päeval, P, 2006-07-30 kell 14:11, kirjutas Alvaro Herrera:
> >> What was idea behind moving vac_update_relstats to a separate
> >> transaction? I'm wondering if it's still needed, if it further enhances
> >> the system so
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, P, 2006-07-30 kell 14:11, kirjutas Alvaro Herrera:
>> What was idea behind moving vac_update_relstats to a separate
>> transaction? I'm wondering if it's still needed, if it further enhances
>> the system somehow, or your patch did s
Hannu Krosing wrote:
> Ühel kenal päeval, P, 2006-07-30 kell 14:11, kirjutas Alvaro Herrera:
> > What was idea behind moving vac_update_relstats to a separate
> > transaction? I'm wondering if it's still needed, if it further enhances
> > the system somehow, or your patch did something differentl
Ühel kenal päeval, P, 2006-07-30 kell 14:11, kirjutas Alvaro Herrera:
> Bruce Momjian wrote:
> >
> > Alvaro has just applied a modified version of this patch.
>
> Hannu, I'm curious:
>
> > Hannu Krosing wrote:
>
> > > Ok, this is a new version of the vacuum patch with the following changes
> >
Bruce Momjian wrote:
>
> Alvaro has just applied a modified version of this patch.
Hannu, I'm curious:
> Hannu Krosing wrote:
> > Ok, this is a new version of the vacuum patch with the following changes
> > following some suggestions in this thread.
> >
> > * changed the patch to affect only l
Alvaro has just applied a modified version of this patch.
---
Hannu Krosing wrote:
> On E, 2005-05-23 at 11:42 -0400, Tom Lane wrote:
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > I can't think of any other cases where
; , Hannu
> > Krosing <[EMAIL PROTECTED]>, Neil Conway
> > <[EMAIL PROTECTED]>, pgsql-
> > [EMAIL PROTECTED]
> > Teema:
> > Re: [PATCHES] PATCH to allow
> > concurrent VACUUMs to not lock each
> >
Saatja:
> > Tom Lane <[EMAIL PROTECTED]>
> > Kellele:
> > Bruce Momjian
> > , Hannu
> > Krosing <[EMAIL PROTECTED]>, Neil Conway
> > <[EMAIL PROTECTED]>, pgsql-
> > [EMAIL PROTECTED]
> >
OTECTED]>, pgsql-
> [EMAIL PROTECTED]
> Teema:
> Re: [PATCHES] PATCH to allow
> concurrent VACUUMs to not lock each
> Kuupäev:
> Wed, 17 Aug 2005 15:40:53 -0400
> (22:40 EEST)
>
> Just for the archives, attached is as far as I'd got
Just for the archives, attached is as far as I'd gotten with cleaning up
Hannu's patch before I realized that it wasn't doing what it needed to
do. This fixes an end-of-transaction race condition (can't unset
inVacuum before xact end, unless you want OldestXmin going backwards
from the point of vi
Bruce Momjian writes:
>> Is there any particular reason for not putting it in 8.1 ?
> I thought there was still uncertainty about the patch. Is there?
Considerable uncertainty, in my mind. What we've got here is some
pretty fundamental hacking on the transaction visibility logic, and
neither H
Hannu Krosing wrote:
> On R, 2005-08-12 at 15:47 -0400, Bruce Momjian wrote:
> > This has been saved for the 8.2 release:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> Is there any particular reason for not putting it in 8.1 ?
I thought there was still uncertainty about th
On R, 2005-08-12 at 15:47 -0400, Bruce Momjian wrote:
> This has been saved for the 8.2 release:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Is there any particular reason for not putting it in 8.1 ?
--
Hannu Krosing <[EMAIL PROTECTED]>
---(end of bro
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Hannu Krosing wrote:
> On E, 2005-07-04 at 10:24 +0300, Hannu Krosing wrote:
> > On P, 2005-07-03 at 12:19 -0400, Tom
On E, 2005-07-04 at 10:24 +0300, Hannu Krosing wrote:
> On P, 2005-07-03 at 12:19 -0400, Tom Lane wrote:
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > Ok, this is a new version of the vacuum patch with the following changes
> > > following some suggestions in this thread.
> >
> > The more I
On P, 2005-07-03 at 12:19 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Ok, this is a new version of the vacuum patch with the following changes
> > following some suggestions in this thread.
>
> The more I look at this, the uglier it looks ... and I still haven't
> seen a
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ok, this is a new version of the vacuum patch with the following changes
> following some suggestions in this thread.
The more I look at this, the uglier it looks ... and I still haven't
seen any convincing demonstration that it *works*, ie doesn't have
On E, 2005-05-23 at 11:42 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > I can't think of any other cases where it could matter, as at least the
> > work done inside vacuum_rel() itself seema non-rollbackable.
>
> VACUUM FULL's tuple-moving is definitely roll-back-able, so
On E, 2005-05-23 at 11:42 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > I can't think of any other cases where it could matter, as at least the
> > work done inside vacuum_rel() itself seema non-rollbackable.
>
> VACUUM FULL's tuple-moving is definitely roll-back-able, so
Hannu Krosing <[EMAIL PROTECTED]> writes:
> I can't think of any other cases where it could matter, as at least the
> work done inside vacuum_rel() itself seema non-rollbackable.
VACUUM FULL's tuple-moving is definitely roll-back-able, so it might be
prudent to only do this for lazy VACUUM. But o
On E, 2005-05-23 at 10:16 -0400, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I'm a little worried about having this set to "true" after a VACUUM is
> > executed, and only reset to false when the next transaction is begun: it
> > shouldn't affect correctness right now, but it see
Neil Conway <[EMAIL PROTECTED]> writes:
> I'm a little worried about having this set to "true" after a VACUUM is
> executed, and only reset to false when the next transaction is begun: it
> shouldn't affect correctness right now, but it seems like asking for
> trouble. Resetting the flag to "fal
Hannu Krosing wrote:
*** src/backend/access/transam/xact.c 28 Apr 2005 21:47:10 - 1.200
--- src/backend/access/transam/xact.c 17 May 2005 22:06:34 -
***
*** 1411,1416
--- 1411,1424
AfterTriggerBeginXact();
/*
+ * mark the transaction as not V
Hannu Krosing wrote:
> On K, 2005-05-18 at 11:54 +0300, Hannu Krosing wrote:
> > The attached patch allows VACUUMS's on small relations to clean up dead
> > tuples while VACUUM or ANALYSE is running for a long time on some big
> > table.
> >
> > This is done by adding a "bool inVacuum" to PGPROC a
On K, 2005-05-18 at 11:54 +0300, Hannu Krosing wrote:
> The attached patch allows VACUUMS's on small relations to clean up dead
> tuples while VACUUM or ANALYSE is running for a long time on some big
> table.
>
> This is done by adding a "bool inVacuum" to PGPROC and then making use
> of it in Get
The attached patch allows VACUUMS's on small relations to clean up dead
tuples while VACUUM or ANALYSE is running for a long time on some big
table.
This is done by adding a "bool inVacuum" to PGPROC and then making use
of it in GetOldestXmin.
This patch is against current CVS head, but should al
27 matches
Mail list logo
