Euler,boa tarde. Verifiquei que haviam alguns registros duplicados em algumas tabelas do meu banco. Eliminei as duplicidades. Fiz o que você recomendou e executei o delete para remover as duplicatas do pg_class. Já consigo fazer o backup. Vou aproveitar e atualizar a versão do SGBD para a 9.3,uma vez que irão refazer esse servidor mesmo. Respondendo à sua pergunta, essa base é de uma secretaria do governo do estado. Um grevista em protesto invadiu o DATA CENTER e andou metendo a mão aqui e desligou todos os servidores na marra.(pode perceber que a segurança aqui é zeroooo!!!). Pra completar dois dias seguidos houve desligamento brusco devido à queda de energia,uma vez que o no-break daqui tá bixado e ninguém resolve. Enfim.... Agradeço muitíssimo a sua ajuda. Att, Deliane Andrade
Em 7 de novembro de 2013 16:05, Euler Taveira <[email protected]>escreveu: > 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 > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
