Em 12/11/2010 11:41, Euler Taveira de Oliveira escreveu:
> André Ormenese (particular) escreveu:
>> relarr_lookup_rel (ctx=0x7fffffffdb40, rel_arr=0x448,
>> nspname=0x800b45000 "pg_catalog", relname=0x800b45040
>> "pg_largeobject",
>> whichCluster=CLUSTER_OLD) at info.c:428
>> 428 for (relnum = 0; relnum< rel_arr->nrels; relnum++)
>> (gdb) p rel_arr->nrels
>> Error accessing memory address 0x450: Bad address.
>> (gdb) p rel_arr->rels->reloid
>> Error accessing memory address 0x448: Bad address.
>>
> Este erro é muito estranho. relnum é realmente zero?
>
> (gdb) p relnum
>
> Veja se o patch [1] resolve o seu problema.
>
> Esta base está corrompida? Você consegue fazer uma consulta em pg_largeobject
> neste banco de dados?
>
>
> [1]
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=71baff1786e0c50b514745c64c4b0947b64bf9d0;hp=9f376e146b2f1fe1bc4d07380f2a047d5c375581
>
>
Durante esta semana constatei que uma tabela esta (acho) corrompida. Eu
não consigo fazer um dump dos dados desta unica tabela.
Veja o log do banco :
LOG: server process (PID 63471) was terminated by signal 11:
Segmentation fault
LOG: terminating any other active server processes
LOG: archiver process (PID 63356) exited with exit code 1
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted; last known up at 2010-11-12
15:52:09 BRST
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: redo starts at 8/CB000068
LOG: invalid magic number 0000 in log file 8, segment 203, offset 1835008
LOG: redo done at 8/CB1BF650
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
E esta é a mensagem do pg_dump :
pg_dump: Dumping the contents of table "cad_sor" failed: PQgetCopyData()
failed.
pg_dump: Error message from server: server closed the connection
unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Se eu der um select * from cad_sor; nesta tabela também dá erro.
Como estou na base de teste, acabei apagando o conteúdo da tabela p/
fazer testes com o pg_upgrade.
Fiz uma consulta em pg_largeobject, sem dar erro, e não retornou nenhuma
linha.
Deletei o conteúdo e passei vaccum analyze no banco.
Fiz a alteração no /PATH_BANCO/contrib/pg_upgrade/controldata.c
Recompilei e instalei o pg_upgrade e pg_upgrade_support
Rodei o pg_upgrade através do gdb, mas continua dando o mesmo erro :
Restoring user relation files
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x800b020b0 (LWP 100137)]
relarr_lookup_rel (ctx=0x7fffffffdb40, rel_arr=0x448,
nspname=0x800b45000 "pg_catalog", relname=0x800b45040
"pg_largeobject",
whichCluster=CLUSTER_OLD) at info.c:428
428 for (relnum = 0; relnum < rel_arr->nrels; relnum++)
(gdb) p relnum
Variable "relnum" is not available.
Como disse no email anterior, achei muito estranho a qtd de parâmetros
na função putenv2. Até tentei pegar a função toda e recompilar, mas aí
não compila dá um monte de erros. O que fiz foi alterar somente a linha
mostrada pelo commitdiff.
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
