Hi, I have more info and I try to explain it better:
First of all I have smtp_utf8 = 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.
- mix collation error should raise 1 error, but next queries should be
work ok, this could be considered and issue right?.
- with "smtputf8_enable = no" I should be able to work without this kind
of issues right?
For modern protocols I can undestant change to utf8, but utf8mb4? this
is much more expensive for the database, is it really necessary?
**
El 14/4/23 a las 20:46, Viktor Dukhovni via Postfix-users escribió:
On Fri, Apr 14, 2023 at 01:06:16PM -0400, Wietse Venema via Postfix-users wrote:
Wietse Venema via Postfix-users:
As for the temp error becoming persistent, the Postfix pgsql: client
code returns an error when it gets an error from all of the hosts
configured in the Postfix pgsql: client configuration file, or when
all hosts have been flagged as 'down'. If a host returns an error
then the Postfix pgsql: client code flags that host as 'down', and
resets that 'down' state after about 60 seconds.
As implemented, the Postfix pgsql: clien code treats all errors as
a connection failure, and skips the connection for 60 seconds. That
may not be optimal when an error is data dependent.
FWIW, the OP's issue was with MySQL, not Postgres... The database
should be configured for client and server encoding of UTF8.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
