Open Bugs / Deficiências de Projeto no MariaDB

Os seguintes problemas são conhecidos e tem prioridade muito alta para serem corrigidos:

• FLUSH TABLES WITH READ LOCK não bloqueia CREATE TABLE ou COMMIT, que pode criar um problema com a posição do log binário ao se fazer um backup completo de tabelas e do log binário.
• ANALYZE TABLE em uma tabela BDB pode, em alguns, casos inutilizar a tabela até que se reinicie o servidor mysqld. Quando isto acontecer você irá ver o seguinte tipo de erro no arquivo de erros do MariaDB.

  001207 22:07:56 bdb: log_flush: LSN past current end-of-log
  

• O MariaDB aceita parenteses na parte FROM, mas os ignora sem aviso. A razão pela qual não são retornados erros é que muitos clientes que geram consultas automaticamente adicionam parentesis na parte FROM mesmo onde eles não são necessários.
• Concatenar muitos RIGHT JOINS ou combinar joins LEFT e RIGHT na mesma consulta podem dar uma resposta incorreta ja que o MariaDB só gera registros NULL para tabelas que precedem um join LEFT ou antes de um join RIGHT. Isto será corrigido na versão 5.0 junto com o suporte a parentesis na parte FROM.
• Não execute ALTER TABLE em uma tabela BDB em que você estiver executando transações multi-instruções não completadas. (A transação provavelmente será ignorada).
• ANALYZE TABLE, OPTIMIZE TABLE e REPAIR TABLE podem causar problemas em tabelas para as quais você estiver usando INSERT DELAYED.
• Fazendo um LOCK TABLE .. e FLUSH TABLES .. não garante que não existem transações não terminadas em progresso na tabela.
• Tabelas BDB são um pouco lentas para abrir. Se você tiver várias tabelas BDB em um banco de dados, gastará muito tempo para usar o cliente MariaDB no banco de dados se você não estiver usando a opção -A ou se você estiver usando rehash. Isto é percebido principalmente quando você tiver um cache de tabelas grandes.
• A replicação utiliza o log a nivel de consulta: o master grava a consulta no log binário. Isto é um rápido, compacto e eficiente método de registro o que funciona perfeitamente na maioria dos casos. Embora nunca tenhamos ouvido sobre um caso ocorrido, há uma chance teórica que o dado no master e slave sejam diferente se uma consulta é feita de tal modo que a modificação do dado é não determinística, isto é, deixar ao desejo do otimizador de consultas (o que geralmente não é uma boa prática, mesmo fora da replicação!). Por exemplo:
  • CREATE ... SELECT ou INSERT ... SELECT que preenchem com zeros ou NULL uma coluna auto_increment.
  • DELETE se você estiver apagando registros de uma tabela que tem chaves estrangeiras com a propriedade ON DELETE CASCADE.
  • REPLACE ... SELECT, INSERT IGNORE ... SELECT se você tiver valores de chaves duplicados nos dados inseridos.

  Se e somente se todos estas consultas NÃO tiverem cláusulas ORDER BY garantindo uma ordem determinística.

  Na verdade, por exemplo para INSERT ... SELECT sem ORDER BY, o SELECT pode retornar registros em uma ordem diferente (no qual resultará em um registro tendo diferentes posições, obtendo um número diferente na coluna auto_increment), dependendo da escolhe feita pelo otimizador no master e slave. Uma consulta será otimizada deiferentemente no master e slave apenas se:

  • Os arquivos usados pelas duas consultas não são exatamente a mesma; por exemplo OPTIMIZE TABLE foi executado nas tabelas master e não nas nas tabelas slave (para corrigir isto, desde o MariaDB, OPTIMIZE, ANALYZE e REPAIR são escritos no log binário).
  • A tabela está armazenada em um mecanismo de armazenamento diferente no master e no slave (pode se executar diferentes mecanismos de armazenamento no metre e no slave: por exemplo, InnoDB ne master e MyISAM no slave, se o slave possuir menos espaço dispponível em disco).
  • The MariaDB buffers' sizes (key_buffer_size etc) are different on the master and slave.
  • O master e slave executam versões diferentes do MariaDB, e o código do toimizador é diferente entre estas versões.

  Este problema também pode afetar a restauração de um banco de dados usando mysqlbinlog|mysql.

  O modo mais fácil de evitar este problema em todos os casos é adicionar uma cláusula ORDER BY para tal consulta não determinística assegure que os registros são sempre armazenados/modificados na mesma ordem. Nas versões futuras do MariaDB adicionaremos automaticamente uma cláusula ORDER BY quando necessário.

Os seguintes problemas são conhecidos e serão corrigidos na hora certa:

• Ao usar funções RPAD, ou qualquer outra função string que termina adicionando espaços em branco a direita, em uma consulta que preisa usar tabelas temporárias para ser rsolvida, todas as strings resultantes serão cortadas a direita (como em RTRIM). Este é um exemplo de uma consulta:

  SELECT RPAD(t1.field1, 50, ' ') AS f2, RPAD(t2.field2, 50, ' ') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON t1.record=t2.joinID ORDER BY t2.record;

  O resultado final deste erro é que o usuário não conseguira espaços em branco do lado direito do campo resultante.

  O comportamento anterior existe em todas as versões do MariaDB.

  A razão disto é devido ao fato de tabelas HEAP, que são usadas primeiro para tabelas temporárias, não são capazes de tratar colunas VARCHAR.

  Este comportamento será corrigido em uma das distribuições da série 4.1.

• Devido ao modo como os arquvos de definições de tabelas são armazenados não se pode usar 255 caracteres (CHAR(255)) em nomes de tabelas, nomes de colunas e enum. Isto está programado para ser corrigido na versão 5.1 quando temos novos arquivos de formatos de definição de tabelas.
• Quando estiver usando SET CHARACTER SET, não é permitido usar caracteres especias no nome do banco de dados, tabelas ou campos.
• Pode-se usar _ ou % com ESCAPE em LIKE ... ESCAPE.
• se você tiver uma coluna DECIMAL com um número armazenado em diferentes formatos (+01.00, 1.00, 01.00), GROUP BY pode considerar cada valor como um valor diferente.
• DELETE FROM merge_table usado sem WHERE irá apenas apagar o mapeamento para a tabela, não apagando tudo nas tabelas mapeadas.
• Você não pode construir em outro diretório quando estiver utilizando MIT-pthreads. Como isto necessitaria de alterações na MIT-pthreads, nós não estamos aptos a corrigí-la.
• BLOB valores não podem ser usados com confiança em GROUP BY, ORDER BY ou DISTINCT. Somente os primeiros bytes (padrão 1024) max_sort_length são usados quando estiver comparando BLOBs nestes casos. Isto pode ser alterado com a opção -0 max_sort_lenght para mysqld. Uma forma de contornar este problema para a maioria dos casos é usar a substring: SELECT DISTINCT LEFT(blob,2048) FROM nome_tabela.
• Cálculos são feitos com BIGINT ou DOUBLE (normalmente, ambos tem o tamanho de 64 bits). Depende da precisão utilizada na função. A regra geral é que funções binárias são feitas com precisão BIGINT, IF e ELT() com precisão BIGINT ou DOUBLE e o resto com precisão DOUBLE. Devemos evitar o uso de valores sem sinal maiores que 63 bits (9223372036854775807) para qualquer outra coisa além de campos binários!
• Todas os campos string, exceto campos do tipo BLOB e TEXTO tem, automaticamente, todos os espaços extras removidos quando recuperados. Para tipos CHAR, isto não tem problema, e pode ser considerado como um recurso de acordo com o ANSI SQL92. O problema é que no MySQL, campos VARCHAR são tratados desta mesma forma.
• Você só pode ter até 255 colunas ENUM e SET em uma tabela.
• Em MIN(), MAX() e outras funções de agrupamente, o MariaDB atualmente compara as colunas ENUM e SET pelo valor de suas strings ao invés da posição relativa da string no conjunto.
• mysqld_safe redireciona todas as mensagens de mysqld para o log mysqld. Um problema com isto é que se você executar o mysqladmin refresh para fechar e reabrir o log, a stdout e a stderr continuam redirecionadas para o log antigo. Se você utiliza --log extensivamente, deverá editar o mysqld_safe para logar em 'hostname'.err em vez de 'hostname'.log; assim você pode facilmente utilizar o espaço do log antigo apagando-o e executando mysqladmin refresh.
• Em instruções UPDATE, colunas são atualizadas da esquerda para a direita. Se você referenciar a uma coluna atualizada, você irá obter o valor atualizado em vez do valor original, por exemplo:

  mysql> UPDATE nome_tabela SET KEY=KEY+1,KEY=KEY+1;
  

  Isto atualiza KEY com 2 no lugar de 1.

• Você pode se referir a múltiplas tabelas em uma mesma consulta, mas você não pode se referir a qualquer tabelas temporárias dada mais de uma vez. Por exemplo, a seguinte instrução não funciona.

  mysql> SELECT * FROM temporary_table, temporary_table AS t2;
  

• RENAME não funciona com tabelas temporárias (TEMPORARY) ou tabelas usadas em uma tabelas MERGE.
• O otimizador pode lidar com o DISTINCT de forma diferente se você estiver usando colunas 'escondidas' em uma join ou não. Em uma join, colunas escondidas são contadas como parte do resultado (mesmo se elas não são mostradas) enquanto que em queries normais colunas escondidas não participam na comparação DISTINCT. Nós provavelmente iremos alterar isto no futuro para nunca comparar as colunas escondidas quando executando DISTINCT.

  um exemplo disto é:

  SELECT DISTINCT mp3id FROM band_downloads
   WHERE userid = 9 ORDER BY id DESC;
  

  and

  SELECT DISTINCT band_downloads.mp3id
   FROM band_downloads,band_mp3
   WHERE band_downloads.userid = 9
   AND band_mp3.id = band_downloads.mp3id
   ORDER BY band_downloads.id DESC;
  

  No segundo caso, você pode obter duas linhas idênticas no MariaDB 3.23.x na série do resultado (porque o campo escondido 'id' pode variar).

  Perceba que isto somente acontece em consultas onde você não tem colunas ORDER BY no resultado, algo não permitido no SQL-92.

• Como o MariaDB permite trabalhar com tipos de tabelas que não suportam transações (e assim não pode fazer rollback em dados) algumas coisas funcionam um pouco diferentes de outros servidores SQL em MariaDB (Isto serve para garantir que o MariaDB nunca necessitará de um rollback para um comando SQL). Porém isto pode ser um pouco estranho em casos que os valores dos campos devem ser verificados na aplicação, mas isto ira fornacer um ótimo ganho de velocidade assim como permite ao MariaDB fazer algumas otimizações que de outro modo seriam muito difíceis para serem feitas.

  Se você informar um valor incorreto em uma coluna, o MySQL, em vez de fazer um rollback, aramzenará o melhor valor possível no campo.

  • Se tentar armazenar um valor fora da faixa em uma coluna numérico, o MariaDB irá armazenar o menor ou maior valor possível no campo.
  • Se tentar armazenar uma string que não comece com um número em uma coluna numérica, o MariaDB irá armazenar 0 na coluna.
  • Se você tentar armazenar NULL em uma coluna que não aceita valores nulos, MariaDB irá armazenar 0 ou '' (string vazia) na coluna. (Este comportamento pode, entretanto, ser alterado com a opção de compilação -DDONT_USE_DEFAULT_FIELDS).
  • O MariaDB permite o armazenamento de alguns valores errados de data em campos do tipo DATE e DATETIME. (Como 2000-02-31 ou 2000-02-00). A idéia é que não é serviço do servidor SQL validar datas. Se o MariaDB pode armazenar uma data e recuperar extamente a mesma data, então o MariaDB armazenará a data. Se a data estiver totalmente errada, o MariaDB irá armazenar a data 0000-00-00 no campo.
  • Se você especificar um valor não suportado para um campo do tipo enum, ele será alterado para o valor de erro 'empty string', com valor numérico 0.
  • Se você definir uma coluna SET com um valor não suportado, o valor será ignorado.
• Se você executar uma PROCEDURE em uma pesquisa que retorna uma série vazia, em alguns casos a instrução PROCEDURE não irá transformar as colunas.
• Criação da tabela do tipo MERGE não verifiva se as tabelas envolvidas são de tipos compatíveis.
• O MariaDB ainda não pode lidar com valores NaN, -Inf e Inf em tipos double. Usá-los causará problemas na exportação e importação de dados. Uma solução intermediária é alterar NaN para NULL (se for possível) e -Inf e Inf para o valor double mínimo ou máximo respectivo possível.
• Se você usar ALTER TABLE para primeiro adicionar um índice UNIQUE a uma tabela usada em uma tabela MERGE e então usar ALTER TABLE para adicionar um índice normal na tabela MERGE, a ordem das chaves será diferente para as tabelas se existir uma chave antiga não única na tabela. Isto é porque o ALTER TABLE coloca chaves UNIQUE antes de chaves normais para ser possível detectar chaves duplicadas o mais cedo o possível.

Os seguintes erros são conhecidos em versões mais antigas do MariaDB:

• Você pode pendurar um processo se você fizer um DROP TABLE em uma tabela entre outras que esteja travada com LOCK TABLES.
• No caso seguinte você pode obter um descarrego de memória para o arquivo core:
  • Tratamento de inserções com atraso tem deixado inserções pendentes na tabela.
  • LOCK table com WRITE
  • FLUSH TABLES
• Antes da versão 3.23.2 do MariaDB um UPDATE que atualizava uma chave com um WHERE na mesma chave podia falhar porque a chave era usada para procurar por registros e a mesma linha poderia ter encontrado vários itens:

  UPDATE nome_tabela SET KEY=KEY+1 WHERE KEY > 100;
  

  Um modo de contornar este erro é utilizar:

  mysql> UPDATE nome_tabela SET KEY=KEY+1 WHERE KEY+0 > 100;
  

  Isto funcionará porque MariaDB não utilizará indices em expressões com a cláusula WHERE.

• Antes da versão 3.23 do MariaDB, todos os tipos numéricos tratados como campos de pontos fixos. Isto significa que você tem que especificar quantas casas decimais um campo de ponto flutuante deve ter. Todos os resultados eram retornados com o número correto de casas decimais.

Para erros específicos na plataforma, vejas as seções sobre compilação e portabilidade. Leia "Instalando uma distribuição com fontes do MariaDB". Leia Apêndice E, Portando para Outros Sistemas.

---

Retornar