logwatchの出力に以下の記録がありました。
 --------------------- Kernel Begin ------------------------

 WARNING:  Segmentation Faults in these executables
    pgpool :  1 Time(s)

 1 Time(s): Code: 8b 44 24 38 4c 8b 3c 24 8d 50 ff 49 8b 84 24 80 00 00 00 4c 89 ff 48 8d 70 01 e8 5f f6 ff ff 48 89 c7 48 89 04 24 49 8b 47 70 <48> 8b 00 48 85 c0 0f 84 c5 01 00 00 49 8b 57 78 31 f6 ff d0 48 89

 ---------------------- Kernel End -------------------------
そこでmessagesを確認しました。

/var/log/messagesの出力
 # cat messages-20230602 | grep 21:35
Jun  1 21:35:32 sakura kernel: Code: 8b 44 24 38 4c 8b 3c 24 8d 50 ff 49 8b 84 24 80 00 00 00 4c 89 ff 48 8d 70 01 e8 5f f6 ff ff 48 89 c7 48 89 04 24 49 8b 47 70 <48> 8b 00 48 85 c0 0f 84 c5 01 00 00 49 8b 57 78 31 f6 ff d0 48 89
Jun  1 21:35:32 sakura systemd[1]: Started Process Core Dump (PID 3000525/UID 0).
Jun  1 21:35:33 sakura systemd-coredump[3000526]: Resource limits disable core dumping for process 2998804 (pgpool).
Jun  1 21:35:33 sakura systemd-coredump[3000526]: Process 2998804 (pgpool) of user 26 dumped core.
Jun  1 21:35:33 sakura systemd[1]: systemd-coredump@7-3000525-0.service: Succeeded.
コアダンプを確認します。
# coredumpctl info -1
           PID: 2998804 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Thu 2023-06-01 21:35:32 JST (10h ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(46500) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 2998804 (pgpool) of user 26 dumped core.
「-1」のオプションは直近のコアダンプを確認するというものです。
マニュアルの記述は以下の通りです。
Show information of a single core dump only, instead of listing all known core dumps.
そういえば最近ちょくちょく同じメッセージがでていたので、すべてのコアダンプを確認します。
# coredumpctl info
           PID: 608872 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Wed 2023-05-24 07:37:23 JST (1 weeks 2 days ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(59504) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 608872 (pgpool) of user 26 dumped core.

           PID: 1636000 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Sun 2023-05-28 01:30:35 JST (5 days ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(37008) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 1636000 (pgpool) of user 26 dumped core.

           PID: 1827919 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Sun 2023-05-28 18:42:12 JST (4 days ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(51772) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 1827919 (pgpool) of user 26 dumped core.

           PID: 1950651 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Mon 2023-05-29 03:30:50 JST (4 days ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(43044) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 1950651 (pgpool) of user 26 dumped core.

           PID: 2998804 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Thu 2023-06-01 21:35:32 JST (10h ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(46500) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 2998804 (pgpool) of user 26 dumped core.

前に同じ事象が発生したときは、php-fpmのrestartで回復したので、とりあえずphp-fpmをrestartしました。
# systemctl restart php-fpm.service
コアダンプはgdbで見られるそうなので、見ようとしたところコアダンプがありませんでした…

# coredumpctl gdb -1
           PID: 2998804 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Thu 2023-06-01 21:35:32 JST (10h ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(46500) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 271c5cf67c8a43e98f20ff425b76fbb4
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 2998804 (pgpool) of user 26 dumped core.

Coredump entry has no core attached (neither internally in the journal nor externally on disk).
ulimitコマンドで確認すると、core file sizeが0でしたので…、unlimitedに変更しました。 
# ulimit -a
core file size          (blocks, -c) 0
# ulimit -c unlimited
# ulimit -a
core file size          (blocks, -c) unlimited
また再起動後も設定を有効にするため、以下のように設定しました。
# emacs /etc/security/limits.d/90-core.conf
90-core.confに以下の内容を追加 
* soft core unlimited
* hard core unlimited
すべてのユーザー(*)に対してソフトおよびハードの core file size を無制限に設定します。
特定のユーザーだけに適用したい場合、* の代わりにユーザー名を使用します。

次にコアダンプをグローバルに有効にします。
# emacs /etc/sysctl.conf
/etc/sysctl.confに以下の内容を追加 
kernel.core_pattern = /coredumpsへのパス/core.%e.%p
fs.suid_dumpable = 2
この設定は、コアダンプファイルのファイル名を設定し、SUIDプログラムでもコアダンプが生成されるようにしています。
設定を反映します。
# sudo sysctl -p
コアダンプを保存するディレクトリが、すべてのユーザーに対して書き込み可能にします。
sudo mkdir -p /coredumpsへのパス
sudo chmod 1777 /coredumpsへのパス
コアダンプが生成されているかどうかをテストするために、クラッシュする簡単なプログラムを作成して実行します。
crash.c 
#include <stdlib.h>

int main() {
    abort();
}
コンパイルして実行し、指定したディレクトリにコアダンプファイルが生成されることを確認します。 
$ gcc -o crash crash.c
$ ./crash
$ ls -l /var/tmp/core/
total 160
-rw------- 1 ap2 ap2 253952 Jun 15 08:09 core.crash.2340294
2023/06/19 追記
まだコアダンプが生成されませんでした。
#  coredumpctl gdb -1
           PID: 1964404 (pgpool)
           UID: 26 (postgres)
           GID: 26 (postgres)
        Signal: 11 (SEGV)
     Timestamp: Wed 2023-06-14 00:43:50 JST (5 days ago)
  Command Line: pgpool: ap3 ap2 127.0.0.1(36308) SELECT
    Executable: /usr/bin/pgpool
 Control Group: /system.slice/pgpool.service
          Unit:
         Slice: system.slice
       Boot ID: 35ca3e38a1bd486194253de42de9c7c7
    Machine ID: 695a939c5d6449a087f6d36503d37bec
      Hostname: sakura
       Storage: none
       Message: Process 1964404 (pgpool) of user 26 dumped core.

Coredump entry has no core attached (neither internally in the journal nor externally on disk).
pgpoolのプロセスのmax core file sizeを確認したところ、SOFTが0になっていました。
# ps ax | grep pgpool | more
3257315 ?        Ss     0:17 /usr/bin/pgpool -f /etc/pgpool-II/pgpool.conf -n
(以下略)

# prlimit 3257315
RESOURCE   DESCRIPTION                             SOFT      HARD UNITS
AS         address space limit                unlimited unlimited bytes
CORE       max core file size                 unlimited unlimited bytes
(以下略)
pgpoolのソフトリミットをunlimitedに変更します。
# prlimit --pid 3257315 --core=unlimited:unlimited
また、pgpoolのサービスユニットファイルを変更して、LimitCOREをinfinityにしておきます。
まずサービスユニットファイルの場所を確認します。
# systemctl status pgpool.service
● pgpool.service - Pgpool-II
   Loaded: loaded (/usr/lib/systemd/system/pgpool.service; enabled; vendor preset: disabled)
以下の通り設定を追加します。
[Unit]
Description=Pgpool-II
After=syslog.target network.target

[Service]

User=postgres
Group=postgres

EnvironmentFile=-/etc/sysconfig/pgpool

LimitCORE=infinity
ExecStart=/usr/bin/pgpool -f /etc/pgpool-II/pgpool.conf $OPTS
ExecStop=/usr/bin/pgpool -f /etc/pgpool-II/pgpool.conf $STOP_OPTS stop
ExecReload=/usr/bin/pgpool -f /etc/pgpool-II/pgpool.conf reload

[Install]
WantedBy=multi-user.target

2023/07/01追記
事象が再現しましたので、コアダンプを確認しようとしたところ、以下のように出力されました。 
# coredumpctl info -1
No match found.
なにか設定にしくじっていると思います…
coredumpctlはsystemdで動く…という表現でいいのかな…のですが、先日の設定のどこかでsystemdと競合する何かを設定してしまっている気がします。
コアダンプファイルを出力するように設定した/var/tmp/core/ディレクトリに、コアダンプファイルが生成されていましたので、とりあえず解析をすることにしました。
# ls -l /var/tmp/core/
-rw------- 1 postgres postgres 154488832 Jun 30 16:59 core.pgpool.3071815
解析方法は初心者のためのコアファイルの解析方法についてを読んで実施しました。
# gdb /usr/bin/pgpool /var/tmp/core/core.pgpool.3071815
GNU gdb (GDB) Red Hat Enterprise Linux 8.2-19.el8
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/pgpool...Reading symbols from /usr/lib/debug/usr/bin/pgpool-4.1.16-1pgdg.rhel8.x86_64.debug...done.
done.

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing

warning: Can't open file (null) during file-backed mapping note processing
[New LWP 3071815]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `pgpool: ap3 ap2 127.0.0.1(34752) SELECT         '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00005589153a0ffc in psql_yylex (yylval_param=yylval_param@entry=0x0, yyscanner=<optimized out>)
    at utils/psqlscan.l:712
712                                                     value = cur_state->callbacks->get_variable(varname,

(gdb) backtrace
#0  0x00005589153a0ffc in psql_yylex (yylval_param=yylval_param@entry=0x0, yyscanner=<optimized out>)
    at utils/psqlscan.l:712
#1  0x00005589153a1a67 in psql_scan (state=state@entry=0x5589164a15d8, query_buf=query_buf@entry=0x7ffd2f6f0250,
    prompt=prompt@entry=0x7ffd2f6f024c) at utils/psqlscan.l:1149
#2  0x0000558915368f0e in multi_statement_query (
    queries=0x558916486de8 "SELECT \r\n\t'\r\n<!-- jQuery library  -->\r\n<script type=\"text/javascript\" src=\"https://code.jquery.com/jquery-1.11.1.min.js\"></script>\r\n<!-- WEB Fonts  -->\r\n<link href=\\'http://fonts.googleapis.com/css?fa"...) at protocol/pool_proto_modules.c:4131
#3  SimpleQuery (frontend=frontend@entry=0x5589164474f8, backend=backend@entry=0x7fb6f19bb9d0, len=107421,
    contents=contents@entry=0x558916486de8 "SELECT \r\n\t'\r\n<!-- jQuery library  -->\r\n<script type=\"text/javascript\" src=\"https://code.jquery.com/jquery-1.11.1.min.js\"></script>\r\n<!-- WEB Fonts  -->\r\n<link href=\\'http://fonts.googleapis.com/css?fa"...) at protocol/pool_proto_modules.c:266
#4  0x000055891536ef30 in ProcessFrontendResponse (frontend=frontend@entry=0x5589164474f8,
    backend=backend@entry=0x7fb6f19bb9d0) at protocol/pool_proto_modules.c:2597
#5  0x0000558915360d6e in read_packets_and_process (frontend=<optimized out>, backend=<optimized out>,
    reset_request=<optimized out>, state=<optimized out>, num_fields=<optimized out>, cont=<optimized out>)
    at protocol/pool_process_query.c:4986
#6  0x00005589153615e3 in pool_process_query (frontend=<optimized out>, backend=<optimized out>,
    reset_request=<optimized out>) at protocol/pool_process_query.c:291
#7  0x000055891535b0f8 in do_child (fds=fds@entry=0x558916445de0) at protocol/child.c:431
#8  0x0000558915332467 in fork_a_child (fds=0x558916445de0, id=57) at main/pgpool_main.c:703
#9  0x0000558915332cd9 in reaper () at main/pgpool_main.c:2855
#10 0x000055891533aa64 in PgpoolMain (discard_status=<optimized out>, clear_memcache_oidmaps=<optimized out>)
    at main/pgpool_main.c:491
#11 0x0000558915330715 in main (argc=<optimized out>, argv=0x7ffd2f700318) at main/main.c:356

(gdb) list
707
708                                             varname = psqlscan_extract_substring(cur_state,
709                                                                                                                      yytext + 1,
710                                                                                                                      yyleng - 1);
711                                             if (cur_state->callbacks->get_variable)
712                                                     value = cur_state->callbacks->get_variable(varname,
713                                                                                                                           PQUOTE_PLAIN,
714                                                                                                                           cur_state->cb_passthrough);
715                                             else
716                                                     value = NULL;

(gdb) info locals
varname = 0x5589164a1668 "first"
value = 
cur_state = 
output_buf = 
yyless_macro_arg = 
yyless_macro_arg = 
yyless_macro_arg = 
yyless_macro_arg = 
yyless_macro_arg = 
yyless_macro_arg = 
yy_current_state = 
yy_cp = 
yy_bp = 0x5589164a7780 ":first"
yy_act = 
yyg =
backtraceで表示されているSQLを検索して実行したところ、Segmentation faultしました。 このSQLはユーザーさんが作成されたもので、現在のPostgreSQLではそもそも動かないSQLであることを確認したので無効化しました。 なぜSegmentation faultするかの原因を探りたかったのですが、元のSQLが複雑すぎることと、現在のシングルクォーテーションのエスケープ方法ではないエスケープ方法を使っていたので諦めました。