Fabrízio Mello
fabriziomello [at] gmail.com
Blog sobre Tecnologia da Informação
No meu arquivo de configuração do pool (pgbouncer.ini) fiz o seguinte:
create or replace function fc_discard_all() returns void as
$$
declare
rComando record;
iVersao integer;
begin
select cast(setting as integer)
into iVersao
from pg_settings
where name ~ 'server_version_num';
if not found then
raise exception 'A versão do PostgreSQL deve ser >= 8.2';
end if;
if iVersao >= 80300 then
execute 'discard all';
return;
end if;
set session authorization default;
reset all;
for rComando in
select name
from pg_prepared_statements
loop
execute 'deallocate '||rComando.name;
end loop;
for rComando in
select name
from pg_cursors
where name not like '%unnamed%'
loop
execute 'close '||rComando.name;
end loop;
unlisten *;
perform pg_advisory_unlock_all();
for rComando in
select distinct
table_schema,
table_name
from information_schema.tables
where table_type = 'LOCAL TEMPORARY'
loop
execute 'drop table if exists '||quote_ident(rComando.table_schema)||'.'||quote_ident(rComando.table_name)||' cascade';
end loop;
return;
end;
$$
language plpgsql;
# pg_dump -U postgres -d jetclass -v -Fc -f banco.backup -n public
pg_dump: reading schemas
pg_dump: reading user-defined functions
pg_dump: reading user-defined types
pg_dump: schema with OID 264202372 does not exist
pg_dump: *** aborted because of error
create or replace function fc_procura_oid(oid) returns boolean as
$$
declare
xOid alias for $1;
lRetorno boolean default false;
lAchou boolean default false;
rTabelas record;
sExecuta text;
begin
for rTabelas in
select pg_class.relname,
'SELECT EXISTS(SELECT oid FROM '||quote_ident(nspname)||'.'||quote_ident(relname)||' WHERE oid = ' as sql_to_search
from pg_attribute
inner join pg_class on pg_class.oid = pg_attribute.attrelid
inner join pg_namespace on pg_namespace.oid = pg_class.relnamespace
where pg_attribute.attname = 'oid'
and pg_class.relkind = 'r'
and pg_namespace.nspname = 'pg_catalog'
order by 1
loop
sExecuta := rTabelas.sql_to_search || xOid || ')';
execute sExecuta into lAchou;
if lAchou then
raise info 'OID % encontrado na tabela %', xOid, rTabelas.relname;
lRetorno := true;
end if;
end loop;
return lRetorno;
end;
$$
language plpgsql;
training=# select fc_procura_oid(16);
INFO: OID 16 encontrado na tabela pg_type
fc_procura_oid
----------------
t
(1 registro)
Esses dias um cliente ligou com problemas no start do PostgreSQL e, verificando nos logs, encontrei o seguinte:
2009-01-07 14:24:15 BRST 3939 LOG: database system was interrupted while in recovery at 2009-01-07 14:19:55 BRST
2009-01-07 14:24:15 BRST 3939 HINT: This probably means that some data is corrupted and you will have to use the last backup for recovery.
2009-01-07 14:24:15 BRST 3939 LOG: checkpoint record is at AF/90DF2348
2009-01-07 14:24:15 BRST 3939 LOG: redo record is at AF/90DF2348; undo record is at 0/0; shutdown FALSE
2009-01-07 14:24:15 BRST 3939 LOG: next transaction ID: 300561523; next OID: 3349191252
2009-01-07 14:24:15 BRST 3939 LOG: next MultiXactId: 347; next MultiXactOffset: 693
2009-01-07 14:24:15 BRST 3939 LOG: database system was not properly shut down; automatic recovery in progress
2009-01-07 14:24:15 BRST 3937 WARNING: autovacuum not started because of misconfiguration
2009-01-07 14:24:15 BRST 3937 HINT: Enable options “stats_start_collector” and “stats_row_level”.
2009-01-07 14:24:15 BRST 3939 LOG: redo starts at AF/90DF238C
2009-01-07 14:24:15 BRST 3940 [unknown] [unknown] [local] LOG: incomplete startup packet
2009-01-07 14:24:16 BRST 3943 postgres postgres [local] FATAL: the database system is starting up
2009-01-07 14:24:16 BRST 3946 postgres postgres [local] FATAL: the database system is starting up
2009-01-07 14:24:16 BRST 3939 LOG: record with zero length at AF/9115D62C
2009-01-07 14:24:16 BRST 3939 LOG: redo done at AF/9115D5D4
2009-01-07 14:24:16 BRST 3939 PANIC: failed to re-find parent key in “2658″ for split pages 173209/173210
2009-01-07 14:24:16 BRST 3937 LOG: startup process (PID 3939) was terminated by signal 6
2009-01-07 14:24:16 BRST 3937 LOG: aborting startup due to startup process failure
2009-01-07 14:24:16 BRST 3938 LOG: logger shutting down
2009-01-07 14:24:16 BRST 3938 LOG: logger shutting down
Não conseguia iniciar o postgresql nem em single-mode… o que fazer então?!?!
Com uma breve pesquisa no Google consegui detectar que era um problema em índices e para solucionar teria de rodar um reindex, etc…. também descobri que já aconteceu esse problema quando rodava o vacuum em bases, e que o mesmo já foi corrigido… até ai tudo bem, mas no meu caso não foi executado um vacuum, o que ocorreu foi alguma falha no servidor (por problemas de queda de energia) e o postgresql não conseguia iniciar de forma alguma.
Fiz algumas tentativas mas todas sem sucesso… mas não tentei usar o pg_resetxlog por não ter certeza dos dados que seriam perdidos com esse procedimento, quis tentar recuperar o máximo de informação possível. Até poderia ter obtido sucesso, mas antes fui investigar o problema dando uma examinada nos fontes do “elefantinho”.
Com um find descobri:
dbseller@dbseller-note07:~/fabrizio/downloads/postgres/src/postgresql-8.1.15$ find . -name “*.c” -exec grep -il “failed to re-find parent key in” {} \;
./src/backend/access/nbtree/nbtpage.c
./src/backend/access/nbtree/nbtinsert.c
Que sorte né (ou azar…rsrsrs)… apenas 2 fontes geram esse log… então resolvi tomar uma medida radial, alterar os fontes e recompilar, então seguem os passos:
1 - Backup Físico do Cluster (antes de qualquer tentativa… para garantir qualquer imprevisto né… heheeh);
2 - Alterei o fonte src/access/nbtree/nbtinsert.c :
de
/* Check for error only after writing children */
if (pbuf == InvalidBuffer)
elog(ERROR, "failed to re-find parent key in \"%s\" for split pages %u/%u",
RelationGetRelationName(rel), bknum, rbknum);
/* Recursively update the parent */
_bt_insertonpg(rel, pbuf, stack->bts_parent,
0, NULL, new_item, stack->bts_offset,
is_only); para
/* Check for error only after writing children */
if (pbuf == InvalidBuffer)
elog(WARNING, "failed to re-find parent key in \"%s\" for split pages %u/%u",
RelationGetRelationName(rel), bknum, rbknum);
else
/* Recursively update the parent */
_bt_insertonpg(rel, pbuf, stack->bts_parent,
0, NULL, new_item, stack->bts_offset,
is_only); Obs: Também poderia ter alterado o fonte nbtpage.c mas verifiquei que no start do postgresql ele não passa por aquele ponto. Os itens em negrito foram as alterações que efetuei.
3 - Compilar/Instalar fontes com esse Hack;
4 - Iniciar o PostgreSQL com o Hack, e desta vez o startup foi concluido com sucesso… heheheh…. quer dizer… com “um pouco mais de sucesso”;
5 - Reindexar o Catálogo do PostgreSQL (REINDEX SYSTEM postgres);
6 - Parar o PostgreSQL com o Hack e iniciar com os binários originais… aqui foi a supresa… funcionou perfeitamente… não ocorreu mais o erro pois o problema foi em índices do catálogo… e nem poderiam ser em outros índices né, uma vez que o banco não verifica índices de bases no startup, com excessão do catálogo;
7 - REINDEX nas outras bases de dados;
8 - Novo Backup das bases de dados (lógico e físico) sem problemas.
Bom pessoal, podem fazer suas críticas… dizerem que minha solução foi meio que “irresponsável”, e concordo plenamente com essa posição e não recomendo a ninguém sair alterando fontes do postgresql que nem fiz pois os resultados podem ser imprevisiveis… mas o importante é que no meu caso funcionou e gostaria de compartilhar com a comunidade essa pequena “aventura”.
Vida longa ao “elefantinho”!!!!