[pgbr-geral] Diferença de dados entre '=' e LIKE
Bom dia pessoal. Tenho um ambiente com a versão 9.2.9 que está com um problema meio bizarro. Se executo um SELECT do tipo SELECT COUNT(*) FROM TABLE WHERE STATUS = 'ATIVA'; retorna menos valores do que: SELECT COUNT(*) FROM TABLE WHERE STATUS LIKE 'ATIVA'; E ai resolvi dar um update nesses campos que não apareciam com '=', primeiramente para um valor qualquer e depois para 'ATIVA' novamente, e então o count dos campos ficaram iguais. Alguém já passou por isso? Algumas infos sobre o ambiente que podem dizer algo a algum de vocês para tentar ajudar nessa. Versão 9.2.9 (Instalado num Ubuntu server 14.04 dia APT, GCC 4.7.2-5) É um ambiente com replicação(No Slave geralmente a diferença do count é ainda maior, sim tem diferença entre o Master e Slave inclusive) Cleiton Domazak Joinville/SC ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Monitoramento banco.
Bom dia pessoal Gostaria de pedir algo que não é diretamente relacionado com o DB mas que me ajudaria bastante. Eu tenho um servidor que roda o PostgreSQL 9.3, com S.O. Centos 6 Eu gostaria de algo que me alterasse se o serviço do DB parou. Alguém sabe como fazer? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Diferença de dados entre '=' e LIKE
On 17-12-2014 07:46, Cleiton Luiz Domazak wrote:
Tenho um ambiente com a versão 9.2.9 que está com um problema meio bizarro.
Se executo um SELECT do tipo
SELECT COUNT(*) FROM TABLE WHERE STATUS = 'ATIVA';
retorna menos valores do que:
SELECT COUNT(*) FROM TABLE WHERE STATUS LIKE 'ATIVA';
E ai resolvi dar um update nesses campos que não apareciam com '=',
primeiramente para um valor qualquer e depois para 'ATIVA' novamente, e
então o count dos campos ficaram iguais.
Alguém já passou por isso?
Você não mostrou qual é o tipo da coluna STATUS e nem qual é a
codificação (encoding) do banco em questão. Vou supor que é char ou
varchar [1][2].
euler@euler=# create table foo1 (a varchar(10));
euler@euler=# insert into foo1 values('ATIVA'),('ATIVA'),('
ATIVA'),('ATIVA ');
euler@euler=# select count(*) from foo1 where a = 'ATIVA';
count
───
2
(1 registro)
euler@euler=# select count(*) from foo1 where a LIKE 'ATIVA';
count
───
2
(1 registro)
Os operadores = e LIKE produzem o mesmo resultado no tipo varchar (que é
o esperado pela maioria das pessoas).
euler@euler=# create table foo2 (a char(10));
euler@euler=# insert into foo2 values('ATIVA'),('ATIVA'),('
ATIVA'),('ATIVA ');
euler@euler=# select count(*) from foo2 where a = 'ATIVA';
count
───
3
(1 registro)
euler@euler=# select count(*) from foo2 where a LIKE 'ATIVA';
count
───
0
(1 registro)
euler@euler=# select count(*) from foo2 where a LIKE 'ATIVA ';
count
───
3
(1 registro)
Já no tipo char, eles se comportam de maneira diferente. No tipo char,
há um preenchimento de espaço em branco ao final da cadeia de caracteres
(caso a cadeia seja menor do que n em char(n)). No caso do operador =,
ao comparar ele ignora os espaços ao final da string para fazer a
comparação (por isso o resultado 3). Isso é algo bizarro do padrão SQL.
O operador LIKE, age normalmente, ou seja, ele considera os espaços
acrescentados pelo char(n) (por isso não temos nenhum casamento ao
especificar 'ATIVA' mas ao acrescentar os espaços no final ele retorna 3).
Versão 9.2.9 (Instalado num Ubuntu server 14.04 dia APT, GCC 4.7.2-5)
É um ambiente com replicação(No Slave geralmente a diferença do count é
ainda maior, sim tem diferença entre o Master e Slave inclusive)
Diferença entre master e escravo não deve existir (a não ser que haja
atraso entre os servidores). Outra coisa é que como você não informou o
tipo de replicação (nativa, Slony, Londiste, etc) não dá para prever se
isso é causado por diferença de codificação. Qual é a codificação em ambos?
[1] http://www.postgresql.org/docs/9.4/static/datatype-character.html
[2]
http://www.postgresql.org/docs/9.4/static/functions-matching.html#FUNCTIONS-LIKE
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Diferença de dados entre '=' e LIKE
O mais bizarro é que se eu importar um dump isso não ocorre. Somente quando
restauro com o basebackup ou com PITR, deixando o sincronismo desativado,
apenas para replicar a base mesmo.
O tipo de campo é VARCHAR.
A codificação dos 2 servers está em en_US.UTF-8
A replicação é nativa e assíncrona.
Em 17 de dezembro de 2014 10:30, Euler Taveira eu...@timbira.com.br
escreveu:
On 17-12-2014 07:46, Cleiton Luiz Domazak wrote:
Tenho um ambiente com a versão 9.2.9 que está com um problema meio
bizarro.
Se executo um SELECT do tipo
SELECT COUNT(*) FROM TABLE WHERE STATUS = 'ATIVA';
retorna menos valores do que:
SELECT COUNT(*) FROM TABLE WHERE STATUS LIKE 'ATIVA';
E ai resolvi dar um update nesses campos que não apareciam com '=',
primeiramente para um valor qualquer e depois para 'ATIVA' novamente, e
então o count dos campos ficaram iguais.
Alguém já passou por isso?
Você não mostrou qual é o tipo da coluna STATUS e nem qual é a
codificação (encoding) do banco em questão. Vou supor que é char ou
varchar [1][2].
euler@euler=# create table foo1 (a varchar(10));
euler@euler=# insert into foo1 values('ATIVA'),('ATIVA'),('
ATIVA'),('ATIVA ');
euler@euler=# select count(*) from foo1 where a = 'ATIVA';
count
───
2
(1 registro)
euler@euler=# select count(*) from foo1 where a LIKE 'ATIVA';
count
───
2
(1 registro)
Os operadores = e LIKE produzem o mesmo resultado no tipo varchar (que é
o esperado pela maioria das pessoas).
euler@euler=# create table foo2 (a char(10));
euler@euler=# insert into foo2 values('ATIVA'),('ATIVA'),('
ATIVA'),('ATIVA ');
euler@euler=# select count(*) from foo2 where a = 'ATIVA';
count
───
3
(1 registro)
euler@euler=# select count(*) from foo2 where a LIKE 'ATIVA';
count
───
0
(1 registro)
euler@euler=# select count(*) from foo2 where a LIKE 'ATIVA ';
count
───
3
(1 registro)
Já no tipo char, eles se comportam de maneira diferente. No tipo char,
há um preenchimento de espaço em branco ao final da cadeia de caracteres
(caso a cadeia seja menor do que n em char(n)). No caso do operador =,
ao comparar ele ignora os espaços ao final da string para fazer a
comparação (por isso o resultado 3). Isso é algo bizarro do padrão SQL.
O operador LIKE, age normalmente, ou seja, ele considera os espaços
acrescentados pelo char(n) (por isso não temos nenhum casamento ao
especificar 'ATIVA' mas ao acrescentar os espaços no final ele retorna 3).
Versão 9.2.9 (Instalado num Ubuntu server 14.04 dia APT, GCC 4.7.2-5)
É um ambiente com replicação(No Slave geralmente a diferença do count é
ainda maior, sim tem diferença entre o Master e Slave inclusive)
Diferença entre master e escravo não deve existir (a não ser que haja
atraso entre os servidores). Outra coisa é que como você não informou o
tipo de replicação (nativa, Slony, Londiste, etc) não dá para prever se
isso é causado por diferença de codificação. Qual é a codificação em ambos?
[1] http://www.postgresql.org/docs/9.4/static/datatype-character.html
[2]
http://www.postgresql.org/docs/9.4/static/functions-matching.html#FUNCTIONS-LIKE
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Informação sobre conversão de tipo automática.
Pessoal, gostaria de saber se isto é um bug ou é algo normal Crio a tabela CREATE TEMP table table_a (field_a time); Efetuo a inserção de um dado, sendo que utilizo o current_timestamp, e o banco efetua a conversão automática para time na hora que insere. insert into table_a values (current_timestamp); Mas se eu efetuo um simples select utilizando tambem o current_timestamp select * from table_a where field_a = current_timestamp; ERROR: operator does not exist: time without time zone = timestamp with time zone LINE 1: select * from table_a where field_a = current_timestamp; ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. Sei que eu deveria efetuar a comparação com time, mais detectamos tal situação, aonde um campo que era para ser timestamp está como time, e as gravações ocorreram normalmente, aonde eu acredito que não deveriam acontecer também como no select. O campo é de uma tabela de log, praticamente não utilizado e por isso não percebemos o erro. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Informação sobre conversão de tipo automática.
Pessoal, gostaria de saber se isto é um bug ou é algo normal Crio a tabela CREATE TEMP table table_a (field_a time); Efetuo a inserção de um dado, sendo que utilizo o current_timestamp, e o banco efetua a conversão automática para time na hora que insere. insert into table_a values (current_timestamp); Mas se eu efetuo um simples select utilizando tambem o current_timestamp select * from table_a where field_a = current_timestamp; ERROR: operator does not exist: time without time zone = timestamp with time zone LINE 1: select * from table_a where field_a = current_timestamp; ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. É normal. A conversão de timestamp para hora é trivial e está na tabela de conversões de tipos, mas o contrário não e não vale para comparações. Note que isso poderia te levar a erro grave de semântica. Sei que eu deveria efetuar a comparação com time, mais detectamos tal situação, aonde um campo que era para ser timestamp está como time, e as gravações ocorreram normalmente, aonde eu acredito que não deveriam acontecer também como no select. O campo é de uma tabela de log, praticamente não utilizado e por isso não percebemos o erro. Simplesmente inclua a conversão no seu SELECT: select * from table_a where field_a = current_timestamp::time; Ou use outra função, a current_time: select * from table_a where field_a = current_time; []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Diferença de dados entre '=' e LIKE
On 17-12-2014 10:00, Cleiton Luiz Domazak wrote: O mais bizarro é que se eu importar um dump isso não ocorre. Somente quando restauro com o basebackup ou com PITR, deixando o sincronismo desativado, apenas para replicar a base mesmo. O tipo de campo é VARCHAR. A codificação dos 2 servers está em en_US.UTF-8 A replicação é nativa e assíncrona. Você disse mas não mostrou o problema (como eu fiz no email anterior -- tabelas, consultas, codificações, etc). Portanto, isso pode ser várias coisas incluindo um índice corrompido ou mesmo um bug. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Monitoramento banco.
On 17-12-2014 07:56, Pedro B. Alves wrote: Gostaria de pedir algo que não é diretamente relacionado com o DB mas que me ajudaria bastante. Eu tenho um servidor que roda o PostgreSQL 9.3, com S.O. Centos 6 Eu gostaria de algo que me alterasse se o serviço do DB parou. Você não especificou que tipo de alerta quer (email, sms, jabber, etc). Existem várias ferramentas no mercado que se encaixam no que você especificou (por exemplo, Nagios, Zabbix, Munin e Cacti). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Monitoramento banco.
Mês passado teve a thread abaixo na lista, talvez te ajude: https://listas.postgresql.org.br/pipermail/pgbr-geral/2014-November/039331.html On Wed, Dec 17, 2014 at 3:52 PM, Euler Taveira eu...@timbira.com.br wrote: On 17-12-2014 07:56, Pedro B. Alves wrote: Gostaria de pedir algo que não é diretamente relacionado com o DB mas que me ajudaria bastante. Eu tenho um servidor que roda o PostgreSQL 9.3, com S.O. Centos 6 Eu gostaria de algo que me alterasse se o serviço do DB parou. Você não especificou que tipo de alerta quer (email, sms, jabber, etc). Existem várias ferramentas no mercado que se encaixam no que você especificou (por exemplo, Nagios, Zabbix, Munin e Cacti). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- *Att.Felipe Lima* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Monitoramento banco.
On 17-12-2014 14:57, Felipe Lima wrote: Mês passado teve a thread abaixo na lista, talvez te ajude: https://listas.postgresql.org.br/pipermail/pgbr-geral/2014-November/039331.html Nenhuma das ferramentas citadas na discussão é o que ele pediu. PS não faça top-posting. Isso bagunça o histórico da lista. Veja como é irônico, o top-posting te induz a responder sempre o último email (neste caso o meu) mas que na verdade a sua resposta seria mais apropriada ao email do Pedro. Só o Google proporciona esse nível de organização para você! -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Monitoramento banco.
http://www.postgresql.org/docs/9.3/static/monitoring.html 2014-12-17 16:07 GMT-02:00 Euler Taveira eu...@timbira.com.br: On 17-12-2014 14:57, Felipe Lima wrote: Mês passado teve a thread abaixo na lista, talvez te ajude: https://listas.postgresql.org.br/pipermail/pgbr-geral/2014-November/039331.html Nenhuma das ferramentas citadas na discussão é o que ele pediu. PS não faça top-posting. Isso bagunça o histórico da lista. Veja como é irônico, o top-posting te induz a responder sempre o último email (neste caso o meu) mas que na verdade a sua resposta seria mais apropriada ao email do Pedro. Só o Google proporciona esse nível de organização para você! -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- -- Thomaz Luiz Santos Linux User: #359356 http://thomaz.santos.googlepages.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Informação sobre conversão de tipo automática.
On 12/17/2014 02:42 PM, Flavio Henrique Araque Gurgel wrote: Pessoal, gostaria de saber se isto é um bug ou é algo normal Crio a tabela CREATE TEMP table table_a (field_a time); Efetuo a inserção de um dado, sendo que utilizo o current_timestamp, e o banco efetua a conversão automática para time na hora que insere. insert into table_a values (current_timestamp); Mas se eu efetuo um simples select utilizando tambem o current_timestamp select * from table_a where field_a = current_timestamp; ERROR: operator does not exist: time without time zone = timestamp with time zone LINE 1: select * from table_a where field_a = current_timestamp; ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. É normal. A conversão de timestamp para hora é trivial e está na tabela de conversões de tipos, mas o contrário não e não vale para comparações. Note que isso poderia te levar a erro grave de semântica. Sei que eu deveria efetuar a comparação com time, mais detectamos tal situação, aonde um campo que era para ser timestamp está como time, e as gravações ocorreram normalmente, aonde eu acredito que não deveriam acontecer também como no select. O campo é de uma tabela de log, praticamente não utilizado e por isso não percebemos o erro. Simplesmente inclua a conversão no seu SELECT: select * from table_a where field_a = current_timestamp::time; Ou use outra função, a current_time: select * from table_a where field_a = current_time; Beleza, sobre a conversão tudo bem, eu só achei estranho tal situação. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Informação sobre conversão de tipo automática.
2014-12-17 14:35 GMT-02:00 Jean Pereira ad...@olostech.com: CREATE TEMP table table_a (field_a time); Efetuo a inserção de um dado, sendo que utilizo o current_timestamp, e o banco efetua a conversão automática para time na hora que insere. insert into table_a values (current_timestamp); Mas se eu efetuo um simples select utilizando tambem o current_timestamp select * from table_a where field_a = current_timestamp; Bem, existe uma diferença básica. Só para exemplificar o conceito, no PostgreSQL as conversões de tipos são tratadas por funções, sendo que existe três tipos de conversões: - explícitas: são aquelas que você deixa claro, exemplo: CAST(current_timestamp AS time) ou current_timestamp::time - implícitas: (em inglês chamados de implicit casts) são aqueles literalmente implícitos, por exemplo a conversão de int para bigint, um int sempre cabe num bigint, logo essa conversão pode ser feita sem perda alguma, *SEMPRE* - implícitas no assinalamento: (em inglês assignment casts) são usadas em operações de atribuição, por exemplo, num INSERT, num UPDATE ou ALTER TABLE ... ALTER ... TYPE (na verdade só conheço esses três, não sei se tem mais). Sabendo disso fica fácil identificar o seu caso. No INSERT o PostgreSQL irá procurar por um implict cast ou assignment cast de timestamptz para time, existindo (e existe) este será usado. Já no SELECT o PostgreSQL irá procurar primeiro por um operador de igualdade entre os dois tipos em questão, se este não existir (e não existe) aí sim ele irá procurar por um implicit cast, que no caso também não existe, logo o erro (não tenho certeza se a ordem é essa operador depois cast, mas creio que seja). Só pra deixar documentado, se for no psql e executar `\dC 'timestamp with time zone'` irá obter: postgres=# \dC 'timestamp with time zone' List of casts Source type | Target type | Function | Implicit? -+-+-+--- abstime | timestamp with time zone| timestamptz | yes date| timestamp with time zone| timestamptz | yes timestamp without time zone | timestamp with time zone| timestamptz | yes timestamp with time zone| abstime | abstime | in assignment timestamp with time zone| date| date| in assignment timestamp with time zone| timestamp without time zone | timestamp | in assignment timestamp with time zone| timestamp with time zone| timestamptz | yes timestamp with time zone| time without time zone | time| in assignment timestamp with time zone| time with time zone | timetz | in assignment (9 rows) A última linha é o cast que foi usado no seu comando INSERT. Resumindo, os hackers do PostgreSQL acharam que seria razoável a conversão de timestamptz para time de forma implícita, mas somente numa atribuição. Espero que tenha esclarecido. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
