>> 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
