Pessoal, apenas comunicando que encontrei a causa do problema.
As 2 queries, uma com = e outra com like:
select count(*) from ef_usuario u
join ef_conta c on c.id_empresa = u.id_empresa
join ef_empresa e on e.id_empresa = u.id_empresa
where c.status = 'ATIVA' and
e.fl_ativo = true;
TOTAL = 27285
A mesma query utilizando LIKE, retorna o numero correto de valores.
select count(*) from ef_usuario u
join ef_conta c on c.id_empresa = u.id_empresa
join ef_empresa e on e.id_empresa = u.id_empresa
where c.status like 'ATIVA' and
e.fl_ativo = true;
TOTAL = 29721
Nos 2 casos o que mudava era o uso do indice, o que poderia indicar o
índice corrompido, recriei e tudo voltou ao normal lidamente, mas ainda não
fazia sentido, pois no server Master esse problema não ocorria.
Checando o índice, ele é o único do tipo HASH(e sem sentido algum, apenas
por sadismo do DEV), já em desuso no PostgreSQ, então a documentação dá o
tapa na cara do DBA.
Caution
Hash index operations are not presently WAL-logged, so hash indexes might
need to be rebuilt with REINDEX after a database crash if there were
unwritten changes. Also, changes to hash indexes are not replicated over
streaming or file-based replication after the initial base backup, so they
give wrong answers to queries that subsequently use them. For these
reasons, hash index use is presently discouraged.
Muito obrigado Euler, seu lembrete pelo indice corrompido me ajudou mto.
Em 17 de dezembro de 2014 15:43, Euler Taveira <[email protected]>
escreveu:
>
> 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
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
