One of our customers reported issue during installation.

Most likely the situation was developed in such a way:

1. Operator started: PostgreSQL
2. Readiness probe (SQL query: select 1) reported that db is ok.
3. The operator started Keycloak and Che Server.
4. Che Server with help on DBCP pool successfully established JDBC connection with validation query `select 1`.
5. PostgreSQL crashed
FATAL: unexpected data beyond EOF in block 26 of relation base/1/2691
HINT: This has been seen to occur with buggy kernels; consider updating your system.
STATEMENT: – MULE_INTERNAL --> BIG5
CREATE OR REPLACE FUNCTION mic_to_big5 (INTEGER, INTEGER, CSTRING, INTERNAL, INTEGER) RETURNS VOID AS '$libdir/euc_tw_and_big5', 'mic_to_big5' LANGUAGE C STRICT PARALLEL SAFE;
COMMENT ON FUNCTION mic_to_big5(INTEGER, INTEGER, CSTRING, INTERNAL, INTEGER) IS 'internal conversion function for MULE_INTERNAL to BIG5';
CREATE DEFAULT CONVERSION pg_catalog.mic_to_big5 FOR 'MULE_INTERNAL' TO 'BIG5' FROM mic_to_big5;
COMMENT ON CONVERSION pg_catalog.mic_to_big5 IS 'conversion for MULE_INTERNAL to BIG5';

child process exited with exit code 1
initdb: removing contents of data directory "/var/lib/pgsql/data/userdata"
performing post-bootstrap initialization ... x
6. Keycloak and Che Server has multiple errors in logs related to the persistent layer

At this moment the root cause of PostgreSQL is unclear.
However, we found that PostgreSQL deployment doesn't contain a liveness probe
that potentially could help us to take the situation under control next time.