Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.
Date
Msg-id 201209261045.56608.andres@2ndquadrant.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Виктор Егоров <vyegorov@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.
List 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 by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: htup header reorganization breaks many extension modules
Next
From: Hannu Krosing
Date:
Subject: Re: Oid registry