Re: AutoVacuum Behaviour Question - Mailing list pgsql-general

From Bruce Momjian
Subject Re: AutoVacuum Behaviour Question
Date
Msg-id 200707172323.l6HNNGI29970@momjian.us
Whole thread Raw
In response to Re: AutoVacuum Behaviour Question  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: AutoVacuum Behaviour Question  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
Is this item closed?

---------------------------------------------------------------------------

Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre@commandprompt.com> writes:
> > > Tom Lane wrote:
> > >> Yeah, we had better investigate some way to clean them up.  It was never
> > >> obvious before that it mattered to get rid of orphan temp tables, but I
> > >> guess it does.
> >
> > > Would it be enough to delete the tuple from pg_class?
> >
> > No, you need a full DROP.  I don't see that that's harder than removing
> > only the pg_class tuple --- the problem in either case is to be sure
> > it's OK.  In particular, how to avoid a race condition against an
> > incoming backend that adopts that BackendId?  Worst-case, you could be
> > deleting a temp table he just made.
>
> Oh, I was just thinking in way for Bruce to get out of his current
> situation.
>
> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-general by date:

Previous
From: mljv@planwerk6.de
Date:
Subject: Re: createing indexes on large tables and int8
Next
From: Alvaro Herrera
Date:
Subject: Re: AutoVacuum Behaviour Question