>> look please http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253295
TL> I wouldn't worry about it. It's probably due to the fact that we tend TL> to release write lock on system catalogs immediately after updating the TL> catalog, instead of holding the lock till commit. ok, but what is best: - leave as is - do REINDEX DASTABASE before VACUUM FULL - stop all transactions before VACUUM FULL TL> That means it's possible for VACUUM FULL to see uncommitted TL> tuples in system catalogs, which it should never do in user tables. if i understand right, after some time vacuum must run without warnings, but after first warning vacuum print this warnings every time until reindex. TL> (This theory does assume that you are making system catalog changes TL> concurrently with running VACUUM, which doesn't entirely square with TL> your statement that database updates are "rare". Perhaps you create TL> and delete temp tables frequently?) oops, it's my mistake. i do SELECT ... INTO TEMPORARY ... instead START TRANSACTION ISOLATION LEVEL SERIALIZABLE CREATE VIEW ... AS SELECT ... what way (create temporary table or set isolation level on transaction) is better? ps: sorry, english it's not my native language ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
