Skip site navigation (1) Skip section navigation (2)

Re: vacuumdb not enough stack items

From: hjeancha(at)freesurf(dot)fr
To: Decibel! <decibel(at)decibel(dot)org>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: vacuumdb not enough stack items
Date: 2008-06-23 11:59:20
Message-ID: 20080623135920.209778s2iyk9se80@webmail-html.freesurf.fr (view raw or flat)
Thread:
Lists: pgsql-admin
Decibel! <decibel(at)decibel(dot)org> a écrit :

> On Jun 21, 2008, at 8:47 AM, hjeancha(at)freesurf(dot)fr wrote:
>> i use postgresql version7.4.7 on i386-pc-linux-gnu, autovacuum is   
>> configured to run on this database.
>> But recently, we lost data for a database, we were able to connect   
>> the database but we couldn't see any table anymore.
>> I suspected a transaction ID wraparound, and to fix it, i just   
>> imported data from a dump file.
>> I tried to execute the following  query:
>> SELECT datname, age(datfrozenxid) FROM pg_database where age  
>> (datfrozenxid)<0;
>> template1=# SELECT datname, age(datfrozenxid) FROM pg_database   
>> where age(datfrozenxid)<0;
>>                 datname                  |     age
>> ------------------------------------------+-------------
>> template0                                |  -597653514
>> ez_info1                                 |  -205024652
>> XtDB                                     |  -205024658
>>
>>
>> Does the negative value of age means that a transaction ID   
>> wraparound has already occured?
>
> That would be my guess.
>
>> Doing a manual vacuumdb on each database raise an error message  saying:
>> vacuumdb: vacuuming of database "ez_info1" failed: ERREUR:  not   
>> enough stack items
>
> That's probably a bug in vacuum, but even so, you'll want to re-  
> initdb if you want to just pull back in from a pg_dump.
>
> If you can take the downtime to do a pg_dump/restore, you should   
> really upgrade to a more recent version. You'll get integrated   
> autovacuum and code that makes wraparound impossible. I would not   
> expect you to have any major code issues going to 8.0 or 8.1. Of   
> course going to 8.3 would be better, but you could run into some   
> compatibility issues. You'll get a performance gain to boot.
> -- 
> Decibel!, aka Jim C. Nasby, Database Architect  decibel(at)decibel(dot)org
> Give your computer some brain candy! www.distributed.net Team #1828
>
>
>



Hello,

We plan to upgrade to postgresql release 8.1 very soon.
But for now, i found that there is a problem with vacuum.
Doing a vaccuum verbose analyze manually on a database,
we got the error "primary keys constraint broken by duplicate key   
«pg_statistic_relid_att_index».
As suggested on this list it's seems to be an index problem.
That could explain why we got "transaction wraparound" for some databases that
were never really vacuumed because of duplicate key error in   
«pg_statistic_relid_att_index».
I red to solve this problem, one must "delete  from pg_statistic" then  
reindex database.
I just want to know:

1) if it's safe to do this, because data is still accessible even for  
databases with transaction wraparound xid.
If This can fix the «pg_statistic_relid_att_index», i will be able to  
vacuum cleanly every databases.

2)
The age(datfrozenxid) for other databases are
  ez_modele                   |  1074290700
  ez_modele2                  |  1074290002
Does that means, if there are not a lot of transactions,  transaction  
wraparound xid won't happen until reaching the limit of 2 billions  
transactions.


Thank you,


In response to

pgsql-admin by date

Next:From: Sava ChankovDate: 2008-06-23 14:13:19
Subject: md5 password authentication does not work when db_user_namespace = on
Previous:From: hjeanchaDate: 2008-06-22 08:54:20
Subject: Re: vacuumdb not enough stack items

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group