On 07-11-2013 13:49, Deliane Andrade wrote:
>>> Descobrir a tabela relacionada:
> SELECT relname FROM pg_class WHERE relfilenode = 20674;
> 
> resultado :  vazio
> 
Veja bem, a consulta que informei foi:

SELECT relname FROM pg_class WHERE relfilenode = 20670;

>         oid ctid cmin cmax relname relfilenode pg_relation_filepath  20673
> -43,11 5 5 pg_toast_20670 2095406497 base/16385/2095406497  20675 -43,12 5 5
> pg_toast_20670_index 2095406499 base/16385/2095406499  20673 -108,39 5 5
> pg_toast_20670 2101671235 base/16385/2095406497  20675 -109,3 5 5
> pg_toast_20670_index 2101671237 base/16385/2095406499
> 
[Bem que você poderia formatar a saída de acordo. Fica difícil ficar
separando linha por linha aqui.]

Parece-me que tanto a entrada na tabela TOAST quanto o seu índice
possuem identificação duplicada. Verifique *todos* os campos da pg_class
antes de remover as duplicatas. Para remover as duplicatas faça:

BEGIN;
-- onde x e y são os números do ctid
DELETE FROM pg_class WHERE relname = '...' AND ctid = '(x,y)';
COMMIT;

O que me deixou curioso foi esses valores negativos do ctid (o mesmo é
unsigned). Você tem certeza que não se enganou na saída? Veja:

euler=# select
oid,cmin,cmax,ctid,relname,relfilenode,pg_relation_filepath(oid) from
pg_class where relname ~ 'xpto';
─[ RECORD 1 ]────────┬─────────────────
oid                  │ 73074
cmin                 │ 0
cmax                 │ 0
ctid                 │ (0,4)
relname              │ xpto_id_seq
relfilenode          │ 73074
pg_relation_filepath │ base/73073/73074
─[ RECORD 2 ]────────┼─────────────────
oid                  │ 73076
cmin                 │ 7
cmax                 │ 7
ctid                 │ (1,3)
relname              │ xpto
relfilenode          │ 73076
pg_relation_filepath │ base/73073/73076
─[ RECORD 3 ]────────┼─────────────────
oid                  │ 73085
cmin                 │ 8
cmax                 │ 8
ctid                 │ (1,4)
relname              │ xpto_pkey
relfilenode          │ 73085
pg_relation_filepath │ base/73073/73085

> Posso apagá-los?
> estão vazios e com data do dia 05/11/2013.
> Por que será?
> 
Não apague ainda. Houve alguma queda ou parada brusca (aka kill -9)?
Vide os logs do dia 05/11 próximo a última hora de escrita do arquivo
(01:42).


-- 
   Euler Taveira                   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a