Make type cache initialization more resilient on re-entry after OOM An out-of-memory failure while initializing the type cache hash tables would issue an ERROR and leave a backend in a partially inconsistent state. Without assertions, the server would crash with a NULL pointer dereference on initialization re-entry when doing a type lookup due to one or both hash tables missing. An assertion would trigger if these are enabled in the build.
This commit changes the ordering of the type cache initialization to become more robust on re-entry after an in-flight allocation failure: - The two hash tables are initialized first, and can only be initialized once. - The initialization is considered as done once the in-progress list is allocated in the CacheMemoryContext. This is now the last allocation step. - Last, the callbacks are registered. These can only fail with a FATAL error, taking down the process so leaving the process in a non-complete state is fine. This is in the same spirit as b85f9c00fb88 and 29fb598b9cad, where random allocation failures can make the backend go crazy in the code paths fixed due to the static states becoming inconsistent. Like the other fixes, this is unlikely going to show up in practice, so no backpatch is done. Reported-by: Alexander Lakhin <[email protected]> Author: Michael Paquier <[email protected]> Reviewed-by: Matthias van de Meent <[email protected]> Discussion: https://postgr.es/m/[email protected] Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/73dab12719eec2996d8b033bb9d8bc2819cb0d4e Modified Files -------------- src/backend/utils/cache/typcache.c | 57 ++++++++++++++++++++++---------------- 1 file changed, 33 insertions(+), 24 deletions(-)
