MDEV-27955: main.func_json_notembedded postfix -make big
While attempting to reduce the iterations per Monty's suggestion in
MDEV-27955, I wasn't able to succeed in arriving at a predictable
value.
While some functions like json_merge_patch where predictably within
the limit on small values, other functions like json_array_append
where still significantly fast to generate a result and not
ER_STATEMENT_TIMEOUT.
So lets leave this as a big test and hope test machine have sufficient
ram for the lower, but still large results previously committed.
MDEV-26781 InnoDB hangs when using SUX_LOCK_GENERIC
The Shared/Update/Exclusive locks that were introduced in
commit 03ca6495df31313c96e38834b9a235245e2ae2a8 (MDEV-24142)
did not work correctly when a futex-like system call interface
was not available.
On all tested implementations (IBM AIX as well as FreeBSD and GNU/Linux
with the futex interface artificially disabled), the old implementation
would cause hangs in some SPATIAL INDEX tests (innodb_gis suite).
On FreeBSD, a hang was also observed in an encryption test.
We will simply emulate the futex system calls with a single mutex
and two condition variables, one for each wait queue. The condition
variables basically shadow the lock words and are used as wait queues,
just like the futex system calls would be.
The storage overhead of ssux_lock_impl will be increased by 32 bits
when using SUX_LOCK_GENERIC. Compared to the futex-based implementation,
the SUX_LOCK_GENERIC implementation has an overhead of
sizeof(pthread_mutex_t)+2*sizeof(pthread_cond_t).
rw_lock: Remove all SUX_LOCK_GENERIC extensions.
pthread_mutex_wrapper: A simple wrapper of pthread_mutex that
implements srw_spin_mutex and srw_mutex for SUX_LOCK_GENERIC.
srw_mutex_impl: Define this also for SUX_LOCK_GENERIC, but in
that case add the fields mutex, cond.
ssux_lock_impl: Define for SUX_LOCK_GENERIC with a minimal difference:
adding readers_cond.
