Re: VACUUM FULL produce warnings
От | spied@yandex.ru |
---|---|
Тема | Re: VACUUM FULL produce warnings |
Дата | |
Msg-id | 53103830203.20040611150139@yandex.ru обсуждение исходный текст |
Ответ на | Re: VACUUM FULL produce warnings (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: VACUUM FULL produce warnings
|
Список | pgsql-general |
>> 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
В списке pgsql-general по дате отправления: