Martijn van Oosterhout wrote:
On Mon, Aug 27, 2007 at 06:57:54PM +0200, Kamil Srot wrote:
Correct...the script does echo "vacuum full;" | $PGDIR/bin/psql -U
postgres $db for each database...
Hope it's correct?
Well, I'd drop the "full" part, it tends to bloat indexes. Also, did
you check it was actually completing (no errors)?
Yes, it completes w/o errors... just VACUUM as output...
OK, I'll drop the full part and do it less often...
Maybe it's it... I did check the wraparound with:
SELECT datname, age(datfrozenxid) FROM pg_database;
In your SQL I see several rows with too high numbers!
They are all "internal" like pg_toast_618854, views and also some
application level indices etc.
Depends what you mean by too high. Anything with XID 1 and 2 is not a
problem, and age returns a really big number for them. Can you give
some examples?
High numbers is near by the bigint limit... 2 billions.
Here you go:
# select xmin, age(xmin) from pg_class;
xmin | age
-----------+------------
2 | 2147483647
2 | 2147483647
2 | 2147483647
2 | 2147483647
2 | 2147483647
2 | 2147483647
236838019 | 539453
2 | 2147483647
2 | 2147483647
231899309 | 5478163
etc.
Basically everythin has the same age 2147483647 with xmin = 1 or xmin =
2.. but the two lines shown...
Actually the same problem happened several minutes ago :-(
Thank you for any hint!
Regards,
--
Kamil
---------------------------(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
