Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.
| От | Andres Freund |
|---|---|
| Тема | Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries. |
| Дата | |
| Msg-id | 201209261045.56608.andres@2ndquadrant.com обсуждение исходный текст |
| Ответ на | Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries. (Виктор Егоров <vyegorov@gmail.com>) |
| Ответы |
Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.
|
| Список | pgsql-hackers |
Hi, On Wednesday, September 26, 2012 07:57:06 AM Виктор Егоров wrote: > I'm afraid I'm exactly in this situation now. :( > Last entry from the 9.1.6 recommended VACUUM (FREEZE, VERBOSE, ANALYZE) It recommended doing a REINDEX first though? I guess you didn't do that? > was: INFO: "meta_version_chunks": found 55363 removable, 32566245 > nonremovable row versions in 450292 out of 450292 pages > DETAIL: 0 dead row versions cannot be removed yet. > There were 588315 unused item pointers. > 0 pages are entirely empty. > CPU 2.44s/5.77u sec elapsed 2150.18 sec. > INFO: vacuuming "pg_toast.pg_toast_16582" > > And here're are the locks held by the VACCUM backend: > select > oid,relname,relkind,relpages,reltuples::numeric(15,0),reltoastrelid,reltoas > tidxid from pg_class > where oid in (select relation from pg_locks where pid = 1380); > oid | relname | relkind | relpages | reltuples | > reltoastrelid | reltoastidxid > -------+----------------------+---------+----------+-----------+----------- > ----+--------------- 16585 | pg_toast_16582 | t | 16460004 | > 58161600 | > 0 | 16587 > 16587 | pg_toast_16582_index | i | 188469 | 58161600 | > 0 | 0 > 16582 | meta_version_chunks | r | 450292 | 32566200 | > 16585 | 0 > > I will not touch anything and would like to get some recommendations on how > to proceed. On Wednesday, September 26, 2012 08:12:37 AM Виктор Егоров wrote: > Forget to mention, that: > - VACUUM is running on the master; > - current state is unchanged for 20 hours. I guess you cannot cancel the vacuum? Last time it was in a cycle without checking interrupts inbetween. Can you restart the server? Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: