V?ctor Rubiella Monfort via Postfix-users:
> Hi, I have more info and I try to explain it better:
>
> First of all I have smtputf8_enable = no (disabled).
>
> I have several databases related with several mysql_virtual maps:
>
> - Some with utf8 + utf8_general_ci collation
>
> - Another ones with latin1 + latin1_spanish_ci.
>
> I'm using mysql-postfix (mysql_table) lookups, not postgres.
> "proxy:mysql:/XXX.cf".
>
> I can reproduce same issue with both cf files (tables with utf8 and
> tables with latin1).
>
> As I say before, the worst part is when error is raised during about 1
> minute all lookups raises failures.
>
> Error is easy to reproduce manually calling to "postmap -q
> "emailWithspecialchar" "proxy:mysql:/XXX.cf"
>
> Debugging I observe 2 things.
>
> - adding CONVERT('%s' using ascii) fix the issue but I don't want/like
> add converts on all my sql queries...
>
> - adding COLLATE utf8_general_ci raises error "this collate is not valid
> for utf8mb4". This error shows me than mysql_table lookup connections
> are using "utf8mb4" charset by default.
>
> My conclusion to hard-solve this issue on my system is transform all
> tables to utf8mb4.
>
> But:
>
> - I don't see any option to change default charset on mysql_table
> connector, maybe should be interesting add this option on configuration
> file.
Is there such an API?
> - mix collation error should raise 1 error, but next queries should be
> work ok, this could be considered and issue right?.
For the Postfix MySQL client the expected result of a query is:
- found,
- not found,
- error.
The client does not distinguish between errors, and all errors have
the same result (skip this connection for 60s). That code is almost
20 years old, so I wonder if you are doing something unusal that
other people aren't doing.
Based on https://dev.mysql.com/doc/c-api/8.0/en/mysql-next-result.html
I suppose that the client could distinguish between
errors that indicate a connection error and other errors. But that
would be a major code change.
It would help if you could show the warning that Postfix logs.
mysql:/file/name: query failed (mysql_next_result): >>>THIS TEXT<<<<
> - with "smtputf8_enable = no" I should be able to work without this kind
> of issues right?
No. With "smtputf8_enable = no", Postfix will not verify that a
query contains malformed text. This can result in errors from the
MySQL server.
On the other hand, with "smtputf8_enable = yes", Postfix will skip
a query that contains malformed UTF-8, thus avoiding errors from
the MySQL server.
> For modern protocols I can undestant change to utf8, but utf8mb4? this
> is much more expensive for the database, is it really necessary?
By design UTF-8 is a multi-byte encoding for all non-ASCII characters.
The only single-byte in UTF-8 is the ASCII subset.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
