Gerald Galster via Postfix-users: > > > Wietse Venema via Postfix-users <postfix-users@postfix.org>: > > > > And here is a more conservative patch for MySQL client retries. > > > > It closes the server connection after every error, and it delays > > making a new server connection only after specific errors. > > > > Closing the connection eliminates the possibility that the client > > becomes stuck. > > dict_mysql.c: In function 'plmysql_connect_single': > dict_mysql.c:709:13: error: too few arguments to function 'plmysql_down_host' > 709 | plmysql_down_host(host); > > > After adding RETRY_CONN_INTV to plmysql_down_host it works. > My version of 20230417-mysql-charset-patch.txt contained > plmysql_down_host(host). > > > Setting charset = testcharset yields: > > postfix/proxymap[14072]: warning: dict_mysql: mysql_set_character_set > 'testcharset' failed: Can't initialize character set testcharset (path: > compiled_in) > postfix/postmap[14078]: fatal: table > proxy:mysql:/etc/postfix/relay_domains.mysql.cf: query error: Application > error > > Mysql connects then pause for about a minute. > > Introducing a simple sql syntax error yields: > > postfix/proxymap[15610]: warning: mysql:/etc/postfix/relay_domains.mysql.cf: > query failed: You have an error in your SQL syntax... > > There is no pause, every new request hits MySQL.
Well, almost. I spent some time this morning analyzing code, because I was suspicious that this 'no delay after error' fix did not cause the code to go into a fast retry loop. The reason it does not loop is that there will be a delay of up to one second, because the delay is in effect while some deadline >= current_time (the time is measured with one-second resolution). While the delay is in effect, I discovered that the MySQL client will reply with "not found" instead of "error". That bug was introduced in Postfix 3.2, a 'missing initialization' error that none of my compilers reported. I can't eliminate the up-to-one-second delay (changing the code to delay while 'deadline > current_time'), because the MySQL client would go into a fast retry loop. Fixing that would require more invasive changes than I can reasonably do in a stable release. Consdering that - the 60-second delay after error has been in effect since the MySQL client was adopted into Postfix on 19991208, - the same 60-second delay afer error exists in the PostgreSQL client, - there have been no other complaints about the 60-second delay, I'll not change the stable Postfix releases except for the "not found instead of error" bug that I mentioned above. Again, thanks for the assistance with testing. I ended up setting up a MySQL test locally. I should have done that 24 years ago. Wietse _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org