Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> The other problem with it is that it's running vacuum() in an
>> indefinite-lifespan context. Perhaps that has something to do with
>> the report we saw awhile back of autovac leaking memory ...
> Hmm, I'm not sure which memory le
Tom Lane escribió:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > I also noticed that inside autovacuum_do_vac_analyze(), we save the old
> > context (which is TopTransactionContext) and restore it back after vacuum()
> > returns. But vacuum() might have started a new transaction invalidating t
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I also noticed that inside autovacuum_do_vac_analyze(), we save the old
> context (which is TopTransactionContext) and restore it back after vacuum()
> returns. But vacuum() might have started a new transaction invalidating the
> saved context. Do we s
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Does this look better?
>
> Yeah, works for me. Please apply.
Applied to HEAD and 8.3.
Thanks, Takahiro-san, for the report!
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company -
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Does this look better?
Yeah, works for me. Please apply.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-h
Alvaro Herrera wrote:
> Tom Lane wrote:
> > That's really, really ugly. I'd rather see the flag passed down to
> > vacuum_rel as a regular function argument. I realize you'll need
> > to touch the signatures of a couple of levels of functions to do that,
> > but a global variable for this seems
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Okay, I'll do that instead. If I do it quickly, will it be present in
> 8.3.1? I think it was already tagged so my guess is it won't.
I think Marc is planning to rebundle this evening, so if you can get
it done in the next few hours...
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > How about this other patch?
>
> That's really, really ugly. I'd rather see the flag passed down to
> vacuum_rel as a regular function argument. I realize you'll need
> to touch the signatures of a couple of levels of functions to d
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> How about this other patch?
That's really, really ugly. I'd rather see the flag passed down to
vacuum_rel as a regular function argument. I realize you'll need
to touch the signatures of a couple of levels of functions to do that,
but a global variabl
ITAGAKI Takahiro wrote:
> I found autovacuum can be canceled by blocked backends even if the vacuum
> is for preventing XID wraparound in 8.3.0 and HEAD. Autovacuum sets
> PROC_VACUUM_FOR_WRAPAROUND flag just before vacuum, but the flag will be
> cleared at the beginning of vacuum; PROC_VACUUM_FOR_
On Fri, Mar 14, 2008 at 7:36 AM, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
>
> I tried to make a patch to exclude PROC_VACUUM_FOR_WRAPAROUND
> from PROC_VACUUM_STATE_MASK and make autovacuum workers to clear
> PROC_VACUUM_FOR_WRAPAROUND by themselves. Is it a reasonable solution?
>
>
Looks go
I found autovacuum can be canceled by blocked backends even if the vacuum
is for preventing XID wraparound in 8.3.0 and HEAD. Autovacuum sets
PROC_VACUUM_FOR_WRAPAROUND flag just before vacuum, but the flag will be
cleared at the beginning of vacuum; PROC_VACUUM_FOR_WRAPAROUND is not set
during the
12 matches
Mail list logo
