PostgreSQL 8.5 vs 9.0

Não é oficial ainda mas parece que não teremos mais uma versão 8.5 do PostgreSQL... a nova versão será 9.0 conforme discussão na lista de desenvolvimento do mesmo [1].

O motivo dessa mudança é o grande número de novas funcionalidades que irá incorporar a nova versão do PostgreSQL... isso é muito interessante pois a evolução do "elefantinho" está cada vez mais acelerada...

Vida longa ao PostgreSQL!!!


[1] http://archives.postgresql.org/pgsql-hackers/2010-01/msg02056.php


Cordialmente,

Fabrízio de Royes Mello
fabriziomello [at] gmail.com

Case PgBouncer 1.3 com PostgreSQL 8.2

Pessoal,

Estou finalizando a implantação do PgBouncer 1.3 com PostgreSQL 8.2 e obtive excelentes resultados só pelo fato de colocar o Pool de Conexões na frente do "postmaster".

Até aqui não temos nada de muito surpreendente a não ser pelo fato de que, segundo a documentação do próprio PgBouncer fala que podemos ter 100% de transparência com o PostgreSQL 8.3 pelo fato do comando "DISCARD" estar presente apartir dessa release.

Como na versão que estamos utilizando, a 8.2, não existe essa implementação então o jeito foi implementar uma PL que "emule" o comportamento do "DISCARD".

Através da lista de discussão da Comunidade Brasileira de PostgreSQL (pgbr-geral), com a ajuda do colega Euler, implementei uma PL para suprir essa falta conforme segue:

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;

No meu arquivo de configuração do pool (pgbouncer.ini) fiz o seguinte:

server_reset_query = SELECT fc_discard_all()


Os únicos efeitos colaterais dessa solução são:

1. Se a base de dados que for acessada não tiver a PL acima criada vai gerar um log de erro, mas não impacta em problemas na conexão
2. Não foi possível implementar uma emulação para o DISCARD PLANS pois, segundo o colega Euler, esse comando veio em conjunto com a funcionalidade de invalidação de planos em funções procedurais, logo não pode ser emulada em versões menores que 8.3
   

Tive de implementar esse recurso pois preciso descartar tabelas temporárias e outros recursos que são utilizados pela minha aplicação.

O modo do pool que estou utilizando é o "session" pois preciso da sessão do inicio ao fim com o mesmo estado.

Se alguém tiver alguma dica e/ou critica estou a disposição.


Cordialmente,

Fabrízio de Royes Mello
fabriziomello [at] gmail.com

PostgreSQL 8.4 Lançado

Há poucas horas foi aunciado na lista pgsql-announce, pelo Sr. Josh Berkus, o lançamento versão 8.4 do PostgreSQL.

Mais informações e a nota oficial de lançamento traduzidas podem ser encontradas em:

http://www.postgresql.org/about/press/presskit84.html.br


Cordialmente,

Fabrízio de Royes Mello
fabriziomello [at] gmail.com

Compilando o pgAdmin 1.10.0 no Ubuntu 9.04

Ontem (30/06/2009) como já anunciado no blog foi liberada a nova versão do pgAdmin, entretanto ainda não foram disponibilizadas versões compiladas do mesmo para Linux.

Então para instalar não teve jeito, tive de fazer download dos fontes e compilar e para isso tive de seguir os seguinte passos:

1) Instalar os pré-requisitos

sudo apt-get install build-essential
sudo apt-get install libxml2-dev
sudo apt-get install libgtk2.0-dev
sudo apt-get install libxslt1-dev
sudo apt-get install postgresql-server-dev-8.3
sudo apt-get install libwxbase2.8-dev
sudo apt-get install libwxgtk2.8-dev

2) Download do pgAdmin

http://www.pgadmin.org/download/


3) Descompactar os fontes

tar xzvf pgadmin3-1.10.0.tar.gz


4) Compilar e instalar

cd pgadmin3-1.10.0
./configure --with-pgsql=/usr/lib/postgresql/8.3 --prefix=/usr/local/pgadmin3
make
make install


5) Agora basta executá-lo

/usr/local/pgadmin3


Uma peculiaridade é que no meu caso tenho o PostgreSQL 8.3 instalado no meu Desktop então utilizei o pacote de desenvolvimento desta versão, mas creio que não exista problema algum em utilizar versões anteriores como a 8.2 ou 8.1.

Outro detalhe é que apesar de eu estar utilizando o Ubuntu 9.04 esse processo deve ser o igual para versões anteriores e até mesmo para o próprio Debian.

Fazendo isso temos o nosso pgAdmin 1.10.0 pronto para ser utilizado, bem simples e rápido.


Cordialmente,

Fabrízo de Royes Mello
fabriziomello [at] gmail.com

Disponibilizado pgAdmin v1.10.0

Pessoal,

Após mais de um ano de desenvolvimento foi disponibilizada a tão esperada versão 1.10.0 do pgAdmin.

Algumas das novas funcionalidades dessa versão:

• Construtor Gráfico de Consultas (Graphical Query Builder)
• Motor de Scripts na ferramenta de consulta (pgScript)
• Suporte melhorado para Postgres Plus Advanced Server e Greeplum Database
• Suporte a "Full Text Search"
• Mecanismo para integração com ferramentas de terceiros
• Suporte para PostgreSQL 8.4
  

Vejam a nota oficial do lançamento:

http://www.postgresql.org/about/news.1107


Cordialmente,

Fabrízio de Royes Mello
fabriziomello [at] gmail.com

Palestra Database Refactoring com PostgreSQL - URCAMP Alegrete/RS

Ontem (30/06/2009) ministrei a palestra de Database Refactoring para os alunos do Curso de Informática da Universidade da Região da Campanha (URCAMP) de Alegrete/RS.

O evento contou com a presença de alunos dos últimos semestres do Curso de Informática bem como de alguns docentes do Curso.

Os slides da palestra estão disponíveis em:

http://www.slideshare.net/fabriziomello/database-refactoring-postgresql-urcamp-alegrete-2009

As fotos também estão disponíveis em:

http://picasaweb.google.com/fabriziomello/UrcampAlegreteRS2009

Agradeço o convite feito pelos professores Cristian Talles e Eveline Guerra bem como a todos que participaram do evento, para mim foi uma honra trocar conhecimento com todos vocês.


Cordialmente,

Fabrízio de Royes Mello
fabriziomello [at] gmail.com

PGCon Brasil 2009 - Chamada de Trabalhos

Está aberta a Chamada de Trabalhos para o PGCon Brasil 2009 - 3a Conferência Brasileira de PostgreSQL.

Se você utiliza o PostgreSQL ou tem essa intenção, não deixe de participar. Seja como palestrante ou visitante você será muito bem vindo ao maior evento brasileiro sobre o "Banco de Dados Open-Source mais poderoso do mundo".

Informações e dicas de publicação também podem ser encontradas em:

http://www.midstorm.org/~telles/2009/05/31/aberta-a-chamada-de-trabalhos-para-o-pgcon-brasil-2009/

Vida longa ao PostgreSQL!!!


Cordialmente,

Fabrízio de Royes Mello
fabriziomello [at] gmail.com

Refatoração de Banco de Dados - Porto Alegre AgileWeekend 2009

Esse final de semana (25 e 26 de abril de 2009) tive a oportunidade de participar, como palestrante, do Porto Alegre AgileWeekend 2009 [1], discursando sobre Refatoração de Banco de Dados (Database Refactoring) [2] utilizando o PostgreSQL.

O evento contou com conteúdo de alto nível, demonstrando cases de sucesso na aplicação de métodos e práticas ágeis no desenvolvimento de software tais como:

- Lean Software Development
- eXtreme Programming
- Scrum
- FDD (Feature-Driven Development), TDD (Test-Driven Developmento, BDD (Behavior-Driven Development)
- etc...

Além do alto nível dos conteúdos apresentados também não posso deixar de mencionar a alta qualidade da organização do evento que beirou a "perfeição" (e sem exageros... mas isso não seria resultado da aplicação prática de algum Métodos Ágil por parte de seus organizadores???).

O que pude perceber ao longo de todas exposições, é que alguns dos objetivos desses "Métodos Ágeis" são a Satisfação do Cliente e Qualidade do Produto entregue (aquilo que buscamos constantemente).

Atualmente existem diversas empresas (inclusive de nível global) investindo em Métodos Ágeis, tais como:
- Borland
- Adobe
- Toyota (Criadora do Lean Software Development, que pode-se dizer que é "pai" de todos métodos ágeis)
- Globo.com
- etc...

Segundo um representante da SUCESU-RS [4]: "Aqui no nosso estado os CIOs das 40 maiores empresas estão olhando com "muito carinho" para os métodos ágeis". Será que isso não pode-se caracterizar uma tendência de mercado????


Outro ponto positivo é que o evento foi bem diversificado, demonstrando além de questões técnicas a respeito de desenvolvimento de software, muita informação Gerencial, no que diz respeito aos objetivos empresariais... as práticas para maximizar resultados e eliminar desperdícios, dentre outros.


Em uma palestra sobre SCRUM foi comentada a utilização de práticas ágeis aplicadas ao setor de Suporte de uma empresa de desenvolvimento de software... em outra o pessoal está utilizando essa "cultura" nos processos administrativos da empresa... então a "Cultura Ágil" vai além do desenvolvimento de software?!?!?! Não surpreendam-se de em algum tempo ouvirmos coisas do tipo "Refatorar Processos de Negócio!"... "Refatorando as Finanças de sua Empresa"... (adoro refatoração... hehehehe)


Abaixo seguem alguns links com informações sobre o evento, a minha palestra e algumas fotos:

[1] Site do Evento
http://agileweekend.guma-rs.org/

[2] Slides da minha Palestra
http://www.slideshare.net/fabriziomello/refatorao-banco-de-dados-agileweekend2009

[3] Fotos do Evento
http://picasaweb.google.com/fabriziomello/Agileweekend2009

[4] Site SUCESU-RS
http://www.rs.sucesu.org.br/

Cordialmente,

Fabrízio de Royes Mello
fabriziomello [at] gmail.com

PostgreSQL - Procurar Determinado OID no Catálogo

Hoje na lista postgresql-br um membro relatou um problema ao executar um pg_dump o qual acusava não encontrar um schema com um determinado OID.

Erro relatado:

# 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

A solução para esse problema é procurar nas tabelas do catálogo (schema pg_catalog) para encontrar o OID que está gerando o erro e deletá-lo da base.

Baseado nessa solução criei uma pequena função em plpgsql para varrer o catálogo e procurar pelo OID problemático:

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;

Para executar essa basta acessar a base via psql (ou até mesmo com pgadmin) e rodar:

training=# select fc_procura_oid(16);
INFO:  OID 16 encontrado na tabela pg_type
 fc_procura_oid 
----------------
 t
(1 registro)

Essa função retorna TRUE caso encontre, emitindo um echo na tela com o nome da(s) tabela(s) onde ele achou, ou FALSE caso negativo.

PostgreSQL - Recuperação de Erro “failed to re-find parent key” no start do processo

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”!!!!