https://mariadb.com/kb/en/library/server-system-variables/#lock_wait_timeout
Since metadata operations may be long (an ALTER could take a very long
time, even days) a high wait time is not a problem, but actually a good
thing. Unless you are seeing lock timeouts that you were not seeing
before, you will not see any impact from reducing the lock wait timeout.
Note, that row lock times for row locking engines are engine specific , ie:
innodb_row_lock_timeout.
On Fri, Oct 18, 2019, 4:28 AM wrote:
> Hi,
>
> When migrating from mariadb 10.1 to 10.3 we noticed that
> the default value for lock_wait_timeout went from 1 year
> to 1 day.
>
> Although 1 day seems more reasonable than 1 year, it seems
> pretty high for a lock_wait.
>
> Does anyone know why this value is so high? Are there any
> rule of thumbs for a good timeout value that won't degrade
> the system and yet allow it to operate as intended?
>
> I know that part of the answer is "it depends on which
> operations your applications are doing". What I don't know
> is if beyond those applications, mariadb needs a specific
> timeout to function properly, for example, when doing a
> mariabackup or flushing tables.
>
> Is anyone else using a timeout value other than the default ones?
>
> My apologies for the naivete of this question.
>
> Thanks!
>
> --josé
>
> ___
> Mailing list: https://launchpad.net/~maria-discuss
> Post to : maria-discuss@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~maria-discuss
> More help : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp
