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
