pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Silvio Brandani <silvio.brandani@tech.sdb.it>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-admin@postgresql.org
Subject: Re: PANIC killing vacuum process
Date: Wed, 03 Nov 2010 18:03:03 +0100
Message-ID: <4CD195C7.9020604@tech.sdb.it> (raw)
In-Reply-To: <8288.1288802501@sss.pgh.pa.us>
References: <4CD1886C.5000503@tech.sdb.it>
	<4CD1476302000025000371FC@gw.wicourts.gov>
	<8288.1288802501@sss.pgh.pa.us>

Tom Lane ha scritto:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>   
>> Silvio Brandani <silvio.brandani@tech.sdb.it> wrote:
>>     
>>> we have develop a script to execute the vacuum full on all tables
>>> of our very big database , since it is a 24 x 7 available system
>>> we have not a timeframe to exec the vacuum full.
>>> so we try with this script running the vauum full table by table
>>> and if the vacuum generate the waiting status for other
>>> connections we kill the vacuum .
>>> [ and get ]
>>> 2010-11-03 14:25:27 CET [19324]: [6-1] PANIC:  cannot abort
>>> transaction 75073917, it was already committed
>>>       
>
>   
>> What version of PostgreSQL is this?
>>     
>
> Anything pre-9.0 might do that; it's one of the known problems with the
> old VACUUM FULL implementation that made us decide to get rid of it.
>
> However, versions that are less than about a year old do have a hack
> that should avoid the PANIC for a query-cancel interrupt ... at the
> cost of ignoring the cancel interrupt, so that's not all that helpful
> a solution here.
>  
>   
>>> Is it possible to softly kill a vacuum process without risk a
>>> panic ?????
>>>       
>  
>   
>> Normally, yes.  VACUUM FULL is more prone to problems than a normal
>> vacuum, especially if you are using an old version.  There are very
>> few circumstances where VACUUM FULL is the right thing to use.
>>     
>
> Indeed.  If you think you need to use VACUUM FULL on a routine basis,
> rethink that.
>
> 			regards, tom lane
>
>   
We were running vacuum full because of a lot of IO problems , so we try 
this way to reorganize tables....

should be better thane normal vacuum or you think the benefits of 
running vacuum full are not so good to run it and a normal vacuum 
analyze is enough ???

thanks,

-- 
Silvio Brandani


---






Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html
Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html
L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme.
--



view thread (11+ messages)  latest in thread

Message-ID: <4CD195C7.9020604@tech.sdb.it>
Permalink:  ../4CD195C7.9020604@tech.sdb.it/
Also on:    postgresql.org/message-id/4CD195C7.9020604@tech.sdb.it

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: silvio.brandani@tech.sdb.it, tgl@sss.pgh.pa.us, Kevin.Grittner@wicourts.gov
  Subject: Re: PANIC killing vacuum process
  In-Reply-To: <4CD195C7.9020604@tech.sdb.it>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox