Re: [GENERAL] NOTICE from the backend
От | Ulf Mehlig |
---|---|
Тема | Re: [GENERAL] NOTICE from the backend |
Дата | |
Msg-id | 199905020848.KAA06727@pandora3.localnet обсуждение исходный текст |
Ответ на | Re: [GENERAL] NOTICE from the backend (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-general |
Vadim Mikheev <vadim@krs.ru> wrote: > Unfortunately, I don't know from where this TID difference comes > and this is very important to find it. After what operations/ > assertions/FATALs you got this vacuum NOTICE? Hello Vadim, since last vacuum without that error message I did several things, but I think the "guilty" operations were performed immediately before that "vacuum analyze". I just constructed some indexes on that table (and other tables connected by triggers to it to fake referential integrity, like in contrib/spi). Afterwards I tried to cluster the indexes. The clustering didn't work (I posted a report on that to pgsql-general yesterday, too. Message included below! Probably the very last thing I did before the "vacuum" was dropping the tables "temp_66c31" etc. from the error message cited in that posting). Are you interested in details about table structure etc.? BTW, as I recognize now, I can't even drop that table, and dumping makes postgreSQL try to fill my harddisk with more data than ever was in that table (it only had 186 records). Fortunately, I did a general pg_dump yesterday before the problem occurred ... o.k., I destroyed the db, reloaded everything, vacuum works now. Unfortunately, I didn't activate any logging, so I can't tell you exactly, what happend. And I maybe shouldn't have destroyed the broken db without makeing a backup copy to analyze it :-( I am sorry for being so unprofessional in providing help to find the error (but it was the first +-severe postgreSQL failure I ever had, so I'm not used to that situation ;-) Please, tell me if you need more information! Thanks for your help, Ulf ---------------------------------------------------------------------- message about "cluster" failure: ================================ Could there be a bug in the 'cluster' command in postgreSQL 6.4? If I try to cluster a table with a name with more than 8 characters, psql says: xxx=> create table x123456789 (xxx text); CREATE xxx=> create index x123 on x123456789 (xxx); CREATE xxx=> cluster x123 on x123456789; ERROR: Relation x1234567 Does Not Exist! If I try this repeatedly, I get: xxx=> cluster x123 on x123456789; ERROR: temp_66c31 relation already exists I'm running PostgreSQL 6.4(.0) on i386 Linux (2.2.6). Please excuse if I overlooked something in the docs! Bye, Ulf ---------------------------------------------------------------------- -- ====================================================================== Ulf Mehlig <umehlig@zmt.uni-bremen.de> Center for Tropical Marine Ecology/ZMT, Bremen, Germany ----------------------------------------------------------------------
В списке pgsql-general по дате отправления: