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 differently than
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 somehow, or
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 in the
PROTECTED], Neil Conway
[EMAIL PROTECTED], 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
]
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 gotten with cleaning
up
Hannu's patch before I realized that it wasn't
Lane [EMAIL PROTECTED]
Kellele:
Bruce Momjian
pgman@candle.pha.pa.us, Hannu
Krosing [EMAIL PROTECTED], Neil Conway
[EMAIL PROTECTED], pgsql-
[EMAIL PROTECTED]
Teema:
Re: [PATCHES] PATCH to allow
concurrent VACUUMs to not lock
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
Bruce Momjian pgman@candle.pha.pa.us 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
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
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 the patch.
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 any
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 look at this,
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 it might
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
bad
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 seems like
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 it might
16 matches
Mail list logo
