Recovery mode with partitioned tables and ANY(NULL) in WHERE clause

Hello everyone,

We're going to introduce in production environment solution based on table
partitioning.

I think we found BUG in version from 11.4 to 11.5 (maybe and previous).

We have one big table, let's say "book". To improve manage and maintenance
we've decided to partition the table in two partitions levels. First based
on ranges of one column and level on another one. After release our changes
on develop stage we've met unexpected behaviour: database randomly went
into recovery mode. After a little investigation we found query that cause
database crash. We've noticed before that in good practices in partitioning
was point saying about limit for one hundred of partitions. We have +/- 400
so we thought it can be problem. For example with memory or something like
that. We've tried to "explain" problematic query to show planner but
explain fails too (without analyze). Finally we've discovered that problem
occures likewise when we operate on empty tables with two ranged partitions
and one default on one level (probably error occurs too on smaller count of
partitions). Below reproduction path:

PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5
20150623 (Red Hat 4.8.5-36), 64-bit, or
PostgreSQL 11.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5
20150623 (Red Hat 4.8.5-36), 64-bit, or
PostgreSQL 11.5, compiled by Visual C++ build 1914, 64-bit.

Table create:
CREATE TABLE book (
id SERIAL,
id_publishing_house BIGINT,
date_of_publish DATE
) PARTITION BY RANGE (id_publishing_house);

-- First level
CREATE TABLE book_default PARTITION OF book DEFAULT;
CREATE TABLE book_10000000 PARTITION OF book FOR VALUES FROM (1) TO
(10000001);
CREATE TABLE book_20000000 PARTITION OF book FOR VALUES FROM (10000001) TO
(20000001);

QUERY:
SELECT * FROM book WHERE id_publishing_house = ANY(NULL::BIGINT[]);

This query is crashing database. What is more interesting:

SELECT * FROM book WHERE id_publishing_house IN (NULL);

works fine.

Logs:

2019-08-09 18:02:29.560 CEST [13500] LOG: database system was shut down at
2019-08-09 18:02:20 CEST
2019-08-09 18:02:29.591 CEST [18256] LOG: database system is ready to
accept connections
2019-08-09 18:02:53.566 CEST [18256] LOG: server process (PID 2076) was
terminated by exception 0xC0000005
2019-08-09 18:02:53.566 CEST [18256] DETAIL: Failed process was running:
SELECT * FROM book WHERE id_publishing_house = ANY(NULL::BIGINT[]);
2019-08-09 18:02:53.566 CEST [18256] HINT: See C include file "ntstatus.h"
for a description of the hexadecimal value.
2019-08-09 18:02:53.566 CEST [18256] LOG: terminating any other active
server processes
2019-08-09 18:02:53.571 CEST [16400] WARNING: terminating connection
because of crash of another server process
2019-08-09 18:02:53.571 CEST [16400] DETAIL: The postmaster has commanded
this server process to roll back the current transaction and exit, because
another server process exited abnormally and possibly corrupted shared
memory.
2019-08-09 18:02:53.571 CEST [16400] HINT: In a moment you should be able
to reconnect to the database and repeat your command.
2019-08-09 18:02:53.594 CEST [4980] WARNING: terminating connection
because of crash of another server process
2019-08-09 18:02:53.594 CEST [4980] DETAIL: The postmaster has commanded
this server process to roll back the current transaction and exit, because
another server process exited abnormally and possibly corrupted shared
memory.
2019-08-09 18:02:53.594 CEST [4980] HINT: In a moment you should be able
to reconnect to the database and repeat your command.
2019-08-09 18:02:53.634 CEST [18256] LOG: all server processes terminated;
reinitializing
2019-08-09 18:02:53.756 CEST [14972] FATAL: the database system is in
recovery mode
2019-08-09 18:02:53.769 CEST [13816] LOG: database system was interrupted;
last known up at 2019-08-09 18:02:29 CEST
2019-08-09 18:02:53.778 CEST [15388] FATAL: the database system is in
recovery mode
2019-08-09 18:02:54.640 CEST [12560] FATAL: the database system is in
recovery mode
2019-08-09 18:02:54.904 CEST [18008] FATAL: the database system is in
recovery mode
2019-08-09 18:02:55.637 CEST [16120] FATAL: the database system is in
recovery mode
2019-08-09 18:02:55.965 CEST [13816] LOG: database system was not properly
shut down; automatic recovery in progress
2019-08-09 18:02:55.972 CEST [13816] LOG: redo starts at 0/168E160
2019-08-09 18:02:55.973 CEST [13816] LOG: redo done at 0/168E160
2019-08-09 18:02:56.037 CEST [18256] LOG: database system is ready to
accept connections

--

Pozdrawiam
Piotr Włodarczyk