Automatically reprepare statements on error 1615

[Jogo27]

Description

This pull request proposes a workaround for a bug in both MySQL and MariaDB. This bug spuriously invalidates prepared statements, forcing the client to reprepare them. The implemented workaround just do that: it automatically reprepares statements when error 1615 is raised. The workaround is optional and controlled by a new DSN parameter named autoReprepare.

Due to the lack of a comprehensive connection mock, I've been unable to implement proper tests for the new code. Discussion on that issue would be welcome.

Checklist

• Code compiles correctly
• Created tests which fail without the change (if possible)
• All tests passing
• Extended the README / documentation, if necessary
• Added myself / the copyright holder to the AUTHORS file

[Jogo27]

PTAL

I've fixed the issue with Go versions 1.11 and 1.12.

[methane]

I can not confirm re-prepare is the right approach.

For example, see this comment.

reprepare does not help because repeat the same problem with full table definition cache:

[Jogo27]

As I understand it, the bug invalidates statements involving views when some event happens on internal caches. To workaround this bug it has been proposed to increase the size of these caches in order to lessen the probability that the situation arises, or to re-prepare the statement in the hope that the unwanted event will not happen again between the preparation and the execution. None of these workaround can guarantee that the bug will not show up again.

When I encountered the bug, it turned out that increasing the size of the cache had almost no effect. I suspect that in my case the bug arises when two goroutines prepare and execute similar requests (involving the same tables and views) "simultaneously". Anyway, re-preparing statements made the bug disappear completely.

Of course I could have taken another approach. Fixing the bug in MariaDB is out of my reach. Not using views does not seem serious to me. Re-preparing statements in the application code would have been more work. A last approach would be to not prepare statements, using interpolateParams. I tried this solution but had some issue when scanning user-defined type. I'll investigate this issue further and create a bug report if needed.

[methane]

I don't have enough evidence to judge the issue is specific to your environment or general issue.

I don't want to merge ad-hoc retry without enough evidence.
So I wait more info from you and other people, hopefully with reproducible example.

[methane]

I close this issue because https://jira.mariadb.org/browse/MDEV-17124 has been fixed.