Impressões do #pgbr2011
Olá, pessoal
Depois de um grande tempo de inatividade estou voltando a escrever e neste retorno vou rascunhar sobre o #pgbr2011 que aconteceu em São Paulo.
Como todos devem saber sou um entusiasta do PostgreSQL e estou presente desde o primeiro evento que ocorreu em São Paulo em 2007. De lá para cá muita coisa aconteceu: o PostgreSQL evolui bastante, e está se tornando cada vez mais sólido no mercado de Banco de Dados, além dele a comunidade brasileira também cresceu, evoluiu tanto no aprendizado técnico como o que tange a questão organizacional (Este será o tema do post).
Precisamos pensar no seguinte: Por que em 2010 não tivemos PGBr e em 2011 sim? A resposta é simples. Em 2010, algumas pessoas se propuseram a organizar o evento, mas por alguns motivos isso não aconteceu, mas agora isso não vem ao caso, afinal já é passado.
O que importa é que em 2011 a mesma comissão organizadora de 2007, 2008 e 2009 e mais alguns agredados tomaram a frente da organização e fizeram acontecer e por este motivo novamente tivemos o evento. Um evento com sucesso total, tanto na quantidade de pessoas que prestigiaram o evento, como também no nível das palestras apresentadas. E isso é algo que precisa/precisava ser elogiado, por isso que quando o meu amigo Dickson Guedes conversou comigo sobre apresentar um Lightning Talk eu topei na hora, na verdade eu já tinha em mente fazer um LT, mas seria uma apresentação sobre Backup, mas depois resolvi mudar o meu tema porque achei que precisava falar nem que rapidamente da organização do #pgbr2011 e foi o que tentei fazer.
Eu gostaria de parabenizar toda a comissão pela organização do evento. Conheços todos e sei que vocês trabalharam arduamente para que o evento fosse possível. Organizar um evento deste porte é muito complicado, exige sacríficos na vida pessoal, profissional e em alguns momentos de ambas, por isso eu fiz questão de falar sobre isso no Lightning Talk e agora faço este registro aqui.
Faço questão de não citar nomes porque certamente vou esquecer de alguém e isso seria completamente injusto porque todos trabalharam duro, claro que alguns mais e outros menos, mas é assim mesmo, uma equipe funciona assim, então pessoal sintam-se todos parabenizados e agradecidos pela organização do evento. Foi um tremendo sucesso e agora é esperarmos os PGDays de 2012 e o PGBr2012.
Um grande abraço a todos.
PGBr 2011
Olá, pessoal
Boa tarde!!! Gostaria de comentar que nesta quinta-feira (03/11) acontecerá a terceira edição do [PGBr 2011], antigo PGCon.
Se possível apareçam por lá. Aguardamos vocês por lá.
Abraços
PGDay São Paulo
Olá, pessoal
Depois de um bom tempo de inatividade estou voltando a escrever aqui :). Para recomeçar vou falar sobre o PGDay SP que ocorreu ontem (22/10/2010) na Fatec Zona Sul em São Paulo.
O evento reuniu um número bastante grande de pessoas para assistir as palestras, isto mostra a força que o PostgreSQL tem :). Eu particularmente fiquei surpreso pelo alto quorum de participantes. Foi um evento onde pude encontrar alguns colegas de PostgreSQL, como os amigos Fábio Telles, Flávio Gurgel, Rodrigo Marins e Marcelo Costa. Além destes, tive a oportunidade de encontrar ex-colegas de empresa (Matheus Espanhol) e também alguns ex-alunos, como a Patrícia e o Juliano. Este último está de parabéns por organizar todo evento. Também queria parabénizar a empresa 4Linux por patrocinar o evento, assim como Fábio Telles representando a Timbira por ajudar nas despesas do coffee, visto que foi um evento gratuito.
Sobre as palestras do evento vou tecer alguns comentários rápidos aqui:
Fábio Telles apresentou uma palestra falando sobre a diferença de backup via pg_dump e o PITR do PostgreSQL, e nos brindou com uma outra palestra falando sobre as funções de janelas, ou mais conhecidas por Window Functions adicionadas na versão 8.4 do PostgreSQL.
Rodrigo Marins falou sobre os problemas/erros que foram executados no Metro de SP e como podemos tirar lições para não comenter os mesmos erros, além disso deu alguns exemplos de boas práticas.
Valter Douglas palestrou sobre o uso do Zabbix e como utiliza-la para monitorar o PostgreSQL. Apresentou como monitorar alguns recursos do PostgreSQL como: Conexões idle, conexões com transações ainda não finalizadas entre outros recursos.
Flávio Gurgel apresentou o Case da Caixa Econômica Federal, que hoje roda em 22.000 (ATMs), isto é, os caixas de auto-atendimento. Também apresentou tópicos de tuning para o sistema operacional Linux (memória compartilhada, algoritmos de escalonamento de I/O) e para o PostgreSQL.
Marcelo Costa comentou sobre o uso de streaming replication em conjunto com o Hot Standby associado a Cloud Computing.
E por fim, Matheus Espanhol apresentou as novidades da versão 9.o do PostgreSQL.
Era isso. Até a próxima.
Abraços
I’m back
Olá, pessoal
Estou de volta após um longo período de inatividade. Em breve novos posts sobre PostgreSQL.
Abraços
PGCon 2009 – Inscrições abertas
Estão abertas as inscrições para o PGCon 2009.
Não perca tempo e faça já sua inscrição e aproveite o maior de todos os eventos sobre PostgreSQL. Clique aqui e confira:
Usando o DBLink para interligar dois bancos PostgreSQL
Pessoal,
Hoje vou apresentar como é possível trocar informações entre bancos de dados PostgreSQL. Apresentarei como isso é possível através do uso do DBLink.
O primeiro passo é instalar o DBLink no banco. Aqui vou considerar que a instalação do PostgreSQL foi realizada de forma compilada e para isso será necessário fazer uso dos arquivos da instalação. Dentro do diretório existe um diretório denominado contrib e dentro deste diretório existe um subdiretório chamado dblink. Para instalar o dblink é necessário realizar a compilação e posteriormente adiciona-lo ao banco desejado.
Para compilar é necessário executar o seguinte comando:
make
make install
Após a execução dos comandos acima será gerado um arquivo chamado dblink.sql. Este arquivo deve ser carregado (importado) no banco desejado. Para demonstrar o seu uso trabalharei com os bancos: banco01 e banco02.
O banco banco01 possui um tabela chamada tabela01 e o banco02 possui uma tabela chamada tabela02. Cada tabela possui um atributo código do tipo inteiro e ambas as tabelas contém 10 registros.
Carregando o arquivo dblink.sql no banco01.
psql banco01 -f dblink.sql
Com o dblink carregado no banco01, o próximo passo é realizar a conexão entre o banco01 e o banco02.
No exemplo, será considerado que estando conectado no banco01 será requisitada uma conexão com o banco02 para ai sim possibilitar a troca de informações entre os dois bancos de dados.
Então vamos a prática:
banco01=# SELECT dblink_connect(‘conexao’,’host=localhost port=9999 user=postgres dbname=banco02′);
dblink_connect
—————-
OK
(1 row)
Alguns parâmetros são informados. O primeiro é um nome para a conexão, e o restante parâmetros normais de uma conexão: hostname, porta, usuário, senha (opcional) e o nome do banco. Como para este exemplo a autenticação esta usando o método trust, o parâmetro password foi omitido.
Com a conexão OK agora é só realizar uma operação qualquer.
Por exemplo, um join entre a tabela01 que pertence ao banco01 e a tabela02 que pertence ao banco02.
banco01=# SELECT tab01.codigo,tab02.codigo FROM tabela01 tab01 INNER JOIN (SELECT * FROM dblink(‘conexao’,’SELECT codigo FROM tabela02′) AS resultado(codigo integer)) tab02 ON tab01.codigo=tab02.codigo;
Um outro exemplo pode ser feito com uma operação de escrita (INSERT, UPDATE OU DELETE).
A partir do banco01 fazendo uma chamada de inserção na tabela02 que está no banco02.
banco01=# SELECT dblink_exec(‘conexao’,’INSERT INTO tabela02 VALUES (generate_series(11,20))’);
dblink_exec
————-
INSERT 0 10
(1 row)
Conferindo:
banco01=# SELECT * FROM dblink(‘conexao’,’SELECT codigo FROM tabela02′) AS resultado(codigo integer);
codigo
——–
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
(20 rows)
Para operações de UPDATE e DELETE o procedimento transcorre da mesma maneira do que do comando INSERT.
Por fim, para encerrar a conexão é necessário executar a seguinte função:
banco01=# SELECT dblink_disconnect(‘conexao’);
dblink_disconnect
——————-
OK
(1 row)
Espero que a dica seja útil. Até uma próxima oportunidade 🙂
Abraços
PostgreSQL 8.4 – Agora com GRANT/REVOKE por coluna
Olá, pessoal
Após um período de inatividade estou voltando com força total e neste retorno aproveito para falar de uma das funcionalidades que entraram no core do PostgreSQL na versão 8.4.
Alguns bancos de dados como o Oracle já possuiam esta característica e o PostgreSQL ainda não, porém a partir da versão 8.4 é possível conceder e retirar privilégios a colunas específicas de uma tabela.
Segue um exemplo bem simples:
Criação de um banco de dados para o exemplo.
postgres=# CREATE DATABASE exemplo_grant_revoke;
Após criado o banco é realizada uma conexão a ele.
postgres=# \c exemplo_grant_revoke
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke”.
Criação de uma tabela para exemplificar a funcionalidade.
exemplo_grant_revoke=# CREATE TABLE tabela01(codigo int PRIMARY KEY,nome varchar(30));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index “tabela01_pkey” for table “tabela01”
CREATE TABLE
Inserção de dois registros na tabela.
exemplo_grant_revoke=# INSERT INTO tabela01 VALUES (1,’Jota.Comm’),(2,’PostgreSQL’);
INSERT 0 2
exemplo_grant_revoke=# SELECT * FROM tabela01;
codigo | nome
——–+————
1 | Jota.Comm
2 | PostgreSQL
(2 rows)
Criação de um usuário para conceder e revocar privilégios.
exemplo_grant_revoke=# CREATE ROLE usuario_grant_revoke LOGIN;
CREATE ROLE
Conexão ao banco de dados com o usuário criado.
exemplo_grant_revoke=# \c exemplo_grant_revoke usuario_grant_revoke
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke” as user “usuario_grant_revoke”.
Realização uma operação de SELECT na tabela criada.
Neste caso ocorrerá um erro pois o usuário usuario_grant_revoke não tem permissão de acesso ao objeto.
exemplo_grant_revoke=> SELECT * FROM tabela01;
ERROR: permission denied for relation tabela01
Verificando as permissões de acesso. Observa-se que o usuário usuario_grant_revoke não possui nenhuma permissão no objeto tabela01.
exemplo_grant_revoke=> \z tabela01
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
——–+———-+——-+——————-+————————–
public | tabela01 | table | |
(1 row)
Conexão com o superuser (postgres).
exemplo_grant_revoke=> \c exemplo_grant_revoke postgres
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke” as user “postgres”.
Concessão do privilégio de SELECT em todas as colunas da tabela.
exemplo_grant_revoke=# GRANT SELECT ON tabela01 TO usuario_grant_revoke;
GRANT
Concessão do privilégio de UPDATE na coluna nome da tabela tabela01.
exemplo_grant_revoke=# GRANT UPDATE(nome) ON tabela01 TO usuario_grant_revoke;
GRANT
Conexão ao banco com o usuário usuario_grant_revoke.
exemplo_grant_revoke=# \c exemplo_grant_revoke usuario_grant_revoke
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke” as user “usuario_grant_revoke”.
Tentativa da operação de UPDATE sobre a coluna código da tabela tabela01. Um erro será exibido visto que o usuário não tem permissão de UPDATE na coluna código. O privilégio foi concedido apenas para a coluna nome.
exemplo_grant_revoke=> UPDATE tabela01 SET codigo=10 WHERE codigo=1;
ERROR: permission denied for relation tabela01
Operação de UPDATE na coluna nome da tabela tabela01.
exemplo_grant_revoke=> UPDATE tabela01 SET nome=’Jota’ WHERE codigo=1;
UPDATE 1
Operação de SELECT em toda a tabela tabela01.
exemplo_grant_revoke=> SELECT * FROM tabela01;
codigo | nome
——–+————
2 | PostgreSQL
1 | Jota
(2 rows)
Vefiricando as permissões do usuário usuario_grant_revoke na tabela tabela01.
exemplo_grant_revoke=> \x
Expanded display is on.
exemplo_grant_revoke=> \z tabela01
Access privileges
-[ RECORD 1 ]————+———————————-
Schema | public
Name | tabela01
Type | table
Access privileges | postgres=arwdDxt/postgres
: usuario_grant_revoke=r/postgres
Column access privileges | nome:
: usuario_grant_revoke=w/postgres
O usuário usuario_grant_revoke possui privilégio de SELECT na tabela (usuario_grant_revoke=r/postgres) e possui privilégio de UPDATE na coluna nome (usuario_grant_revoke=w/postgres).
Conexão ao banco.
exemplo_grant_revoke=> \c exemplo_grant_revoke postgres
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke” as user “postgres”.
Remoção dos privilégios concedidos.
exemplo_grant_revoke=# REVOKE SELECT ON tabela01 FROM usuario_grant_revoke;
REVOKE
exemplo_grant_revoke=# REVOKE UPDATE(nome) ON tabela01 FROM usuario_grant_revoke;
REVOKE
Conexão ao banco com o usuário usuario_grant_revoke.
exemplo_grant_revoke=# \c exemplo_grant_revoke usuario_grant_revoke
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke” as user “usuario_grant_revoke”.
A partir de agora o usuario usuario_grant_revoke não possui mais nenhum privilégio na tabela tabela01.
exemplo_grant_revoke=> SELECT * FROM tabela01;
ERROR: permission denied for relation tabela01
exemplo_grant_revoke=> UPDATE tabela01 SET nome=’Jota.Comm’ WHERE codigo=1;
ERROR: permission denied for relation tabela01
Verificando os privilégios.
exemplo_grant_revoke=> \z tabela01
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
——–+———-+——-+—————————+————————–
public | tabela01 | table | postgres=arwdDxt/postgres |
(1 row)
Espero que tenha sido claro e didático no exemplo. Até a próxima.
Abraços
PGCon 2009 – Grade oficial do evento
Maior evento sobre PostgreSQL da América Latina acontece em Campinas.
A Unicamp já se prepara para receber a “3ª Conferência Brasileira de PostgreSQL” ou simplesmente PGCon Brasil 2009.
Nos dias 23 e 24 de outubro, centenas de estudantes e profissionais de TI participarão do maior evento latino-americano sobre o mais poderoso sistema gerenciador de banco de dados de código livre do mundo, o PostgreSQL.
A programação completa da Conferência já foi confirmada. O evento contará com palestras, tutoriais e os já consagrados Hacker Talks e Lightning Talks. Estarão presentes desenvolvedores nacionais do PostgreSQL como Euler Taveira e Francisco Figueiredo Jr, internacionais como Bruce Momjian, Magnus Hagander além de profissionais reconhecidos no Brasil como Fernando Ike, Roberto Mello, Leandro Dutra entre outros.
Na programação, estarão temas como as últimas novidades da versão 8.4 do PostgreSQL, técnicas de monitoramento, segurança, ajustes de desempenho e muito mais.
Mais informações sobre o evento, podem ser obtidas no site oficial em: http://pgcon.postgresql.org.br/2009/index.php
Abraços
Descobrindo a definição de chave primária (primary key) e chave estrangeira (foreign key)
Olá, pessoal
Na última semana surgiu uma pergunta na lista pgbr-geral sobre como descobrir a definição das restrições (constraints) de chave primária (primary key) e chave estrangeira (foreign key). Então aproveito para escrever um pouquinho sobre o assunto.
Essa informação não é encontrada diretamente nas tabelas e visões do catálogo do PostgreSQL, mas sim através de uma função chamada pg_get_constraintdef(oid), onde o parâmetro oid é o oid da constraint e que pode ser encontrado na tabela pg_constraint. Por exemplo, existe uma visão chamada pg_indexes que mostra as definições dos índices, porém se pararmos para analisar esta consulta veremos que para apresentar a definição dos índices é utilizada uma função chamada pg_get_indexdef(oid) semelhante a função usada para extrair a definição das restrições (constraints).
Abaixo segue a consulta para identificar o nome da tabela e suas definições de chave primária (primary key) e chave estrangeira (foreing key). Para encontrar essa informação é necessário o uso das tabelas de sistema pg_class e pg_constraint. Coloquei também a tabela pg_namespace que é onde são armazenados os esquemas existentes do PostgreSQL.
SELECT pg_class.relname AS nome_da_tabela,
pg_get_constraintdef(pg_constraint.oid) AS definicao_da_restricao
FROM pg_namespace JOIN pg_class ON pg_namespace.oid=pg_class.relnamespace
JOIN pg_constraint ON pg_class.oid=pg_constraint.conrelid
WHERE pg_namespace.nspname=’public’
AND pg_class.relkind=’r’
ORDER BY pg_class.relname;
O resultado desta consulta apresenta o nome da tabela e a sua respectiva definição de chave primária (primary key) e chave estrangeira (foreign key). Caso a tabela não possua chave primária e/ou chave estrangeira a mesma não será retornada por esta consulta. Neste caso seria necessário substituir o INNER JOIN por um LEFT OUTER JOIN. A palavra OUTER no LEFT OUTER JOIN é opcional.
E a sua implementação ficaria assim:
SELECT pg_class.relname AS nome_da_tabela,
pg_get_constraintdef(pg_constraint.oid) AS definicao_da_restricao
FROM pg_namespace JOIN pg_class ON pg_namespace.oid=pg_class.relnamespace
LEFT OUTER JOIN pg_constraint ON pg_class.oid=pg_constraint.conrelid
WHERE pg_namespace.nspname=’public’
AND pg_class.relkind=’r’
ORDER BY pg_class.relname;
Na cláusula WHERE existem duas restrições: pg_namespace.nspname=’public’ restringe em qual esquema serão procurados os objetos, neste caso apenas no esquema public. Se for necessário procurar em mais de um esquema pode-se substituir a condição pg_namespace.nspname=’public’ por pg_namespace.nspname IN (‘public’, ‘outro_esquema’). A condição pg_class.relkind=’r’ restringe que só serão pesquisados os objetos do tipo tabela. Esta restrição é importante pois a tabela pg_class armazena outros objetos como: índices, seqüências, visões, tipos compostos e tabelas toast. Esta condição é necessária devido ao join com a tabela pg_namespace. Se essa junção for retirada não é necessária esta restrição.
Se for de interesse é possível mostrar o nome da restrição (constraint) através do atributo conname que está armazenado na tabela pg_constraint.
Era isso. Fiquem a vontade para comentários.
Abraços
Problema com o PAM
Olá, pessoal
Estes dias me deparei com um problema um tanto curioso: Estava logado em um servidor com o usuário root e quando tentava fazer o seguinte comando: su postgres ou su para qualquer outro usuário era solicitada a senha para o usuário, o que de passagem é muito estranho, visto que logado como usuário root é possível assumir a identidade de qualquer outro usuário.
Quebrei um pouco a cabeça e nada da solução, foi então que resolvi consultar o Sr. Fernando Ike (Fike) e ele me disse que isso deveria ser problema do PAM, dito e feito. O problema é que a seguinte linha:
auth sufficient pam_rootok.so do arquivo /etc/pam.d/su estava comentada. Foi descomentar a linha e já era possível assumir a identidade de qualquer usuário sem que a senha fosse solicitada.
Aproveito para agradecer o Fike pela ajuda 🙂
Abraços
Jota.Comm 