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
