ErogameScape －エロゲー批評空間

PostgreSQL

2022年12月01日20:00

カテゴリ: PostgreSQL

PostgreSQLのシーケンスで増やす値を1から2に変更する

ap2=# \d campaignlist_id_seq
                    Sequence "public.campaignlist_id_seq"
  Type  | Start | Minimum |       Maximum       | Increment | Cycles? | Cache
--------+-------+---------+---------------------+-----------+---------+-------
 bigint |     1 |       1 | 9223372036854775807 |         1 | no      |     1
Owned by: public.campaignlist.id

ap2=# ALTER SEQUENCE public.campaignlist_id_seq INCREMENT 2;
ALTER SEQUENCE
ap2=# \d campaignlist_id_seq
                    Sequence "public.campaignlist_id_seq"
  Type  | Start | Minimum |       Maximum       | Increment | Cycles? | Cache
--------+-------+---------+---------------------+-----------+---------+-------
 bigint |     1 |       1 | 9223372036854775807 |         2 | no      |     1
Owned by: public.campaignlist.id

ドキュメント

2022年11月13日16:11

カテゴリ: PostgreSQL

.pgpassの書式

pg_basebackupコマンドに--write-recovery-confオプションをつけて実行すると、postgresql.auto.confが生成されます。
その中身は

# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
primary_conninfo = 'user=[ユーザー名] passfile=''/var/lib/pgsql/.pgpass'' channel_binding=prefer host=[ホスト名] port=5432 sslmode=prefer sslcompression=0 sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres target_session_attrs=any'

のようになっています。
pg_basebackupをするためのユーザーがバックアップ元に接続するためにパスワードが必要な場合、そのパスワードを.pgpassに書くことができます。
.pgpassの書式は、34.16. パスワードファイルの通りです。
具体的には

erogamescape.dyndns.org:5432:replication:[ユーザー名]:[パスワード]

となります。
また、.pgpassの権限は600でなければなりません。
600でないとログにエラーが出力されます。

WARNING: password file "/var/lib/pgsql/.pgpass" has group or world access; permissions should be u=rw (0600) or less

2022年11月13日16:00

カテゴリ: PostgreSQL

PostgreSQL13からpg_basebackupコマンドの進捗を確認できるようになりました。

PostgreSQL13からpg_basebackupコマンドの進捗をバックアップ元でも確認できるようになりました。

pg_basebackupコマンドの実行の際に-Pオプションをつけて実行すれば、実行の進捗を確認できるので、バックアップ元で進捗状況を確認できなくてもいいとは思うのですが、-Pをつけわすれて実行してしまった場合、

pg_basebackup: starting background WAL receiver

と表示されてから何も応答がなくて、いつバックアップが終わるのかわからなくなった…というときに重宝します。
バックアップ元で

[postgres@sakura 15]$ psql
psql (15.1)
Type "help" for help.

postgres=# \x
Expanded display is on.
postgres=#  SELECT * FROM pg_stat_progress_basebackup;
(0 rows)

とSELECT * FROM pg_stat_progress_basebackup;で確認できます。
バックアップ先でpg_basebackupコマンドを実行してから、バックアップ元でSELECT * FROM pg_stat_progress_basebackup;を実行すると

Sun 13 Nov 2022 11:45:38 AM JST (every 2s)

-[ RECORD 1 ]--------+---------------------------------
pid                  | 2700275
phase                | waiting for checkpoint to finish
backup_total         | 
backup_streamed      | 0
tablespaces_total    | 0
tablespaces_streamed | 0

と進捗が表示されます。
このとき

postgres=#  \watch

とwatchコマンドを実行すると、SELECT * FROM pg_stat_progress_basebackup;を淡々と実行してくれます。
実行の様子は以下の通りです。

Sun 13 Nov 2022 11:45:54 AM JST (every 2s)

-[ RECORD 1 ]--------+---------------------------------
pid                  | 2700275
phase                | waiting for checkpoint to finish
backup_total         | 
backup_streamed      | 0
tablespaces_total    | 0
tablespaces_streamed | 0

Sun 13 Nov 2022 11:45:56 AM JST (every 2s)

-[ RECORD 1 ]--------+-------------------------
pid                  | 2700275
phase                | streaming database files
backup_total         | 13075364864
backup_streamed      | 15485440
tablespaces_total    | 1
tablespaces_streamed | 0

Sun 13 Nov 2022 11:45:58 AM JST (every 2s)

-[ RECORD 1 ]--------+-------------------------
pid                  | 2700275
phase                | streaming database files
backup_total         | 13075364864
backup_streamed      | 36467200
tablespaces_total    | 1
tablespaces_streamed | 0

Sun 13 Nov 2022 11:46:00 AM JST (every 2s)

-[ RECORD 1 ]--------+-------------------------
pid                  | 2700275
phase                | streaming database files
backup_total         | 13075364864
backup_streamed      | 57504768
tablespaces_total    | 1
tablespaces_streamed | 0

[参考文書]
PostgreSQL13 検証レポート

2022年10月22日00:07

カテゴリ: PostgreSQL

standby.signalを作成したのにPostgreSQLがスタンバイモード(standby mode)で起動しない

standby.signalを作成したのにPostgreSQLがスタンバイモード(standby mode)で起動しませんでした。

[postgres@localhost data]$ touch standby.signal
[postgres@localhost data]$ exit
ログアウト
[root@localhost data]# systemctl start postgresql-15.service
[root@localhost data]# systemctl status postgresql-15.service
● postgresql-15.service - PostgreSQL 15 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-15.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2022-10-21 23:47:47 JST; 3min 0s ago
     Docs: https://www.postgresql.org/docs/15/static/
  Process: 9282 ExecStartPre=/usr/pgsql-15/bin/postgresql-15-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
 Main PID: 9288 (postmaster)
    Tasks: 7 (limit: 49457)
   Memory: 92.7M
   CGroup: /system.slice/postgresql-15.service
           ├─9288 /usr/pgsql-15/bin/postmaster -D /var/lib/pgsql/15/data/
           ├─9289 postgres: logger
           ├─9290 postgres: checkpointer
           ├─9291 postgres: background writer
           ├─9293 postgres: walwriter
           ├─9294 postgres: autovacuum launcher
           └─9295 postgres: logical replication launcher
[root@localhost data]# su - postgres
[postgres@localhost data]$ /usr/pgsql-15/bin/pg_ctl -p 5433 promote
pg_ctl: サーバーを昇格できません; サーバーはスタンバイモードではありません

PostgreSQL 12の新機能をいくつか試してみたの「recovery.confのpostgresql.confへの統合」を拝見したところ、

$ ls -l rep/data/standby.signal
-rw------- 1 kazu kazu 0 12月 18 14:43 rep/data/standby.signal

と、standby.signalの権限が600でしたので、600にしたところスタンバイモードで立ち上がりました。

[postgres@localhost data]$ ls -l standby.signal
-rw-r--r-- 1 postgres postgres 0 10月 21 23:50 standby.signal
[postgres@localhost data]$ chmod 600 standby.signal
[root@localhost data]# systemctl start postgresql-15.service
[root@localhost data]# systemctl status postgresql-15.service
● postgresql-15.service - PostgreSQL 15 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-15.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2022-10-21 23:53:44 JST; 2s ago
     Docs: https://www.postgresql.org/docs/15/static/
  Process: 9950 ExecStartPre=/usr/pgsql-15/bin/postgresql-15-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
 Main PID: 9955 (postmaster)
    Tasks: 6 (limit: 49457)
   Memory: 93.0M
   CGroup: /system.slice/postgresql-15.service
           ├─9955 /usr/pgsql-15/bin/postmaster -D /var/lib/pgsql/15/data/
           ├─9957 postgres: logger
           ├─9958 postgres: checkpointer
           ├─9959 postgres: background writer
           ├─9960 postgres: startup recovering 0000000100000005000000BD
           └─9961 postgres: walreceiver

2022年10月21日19:00

カテゴリ: PostgreSQL

[解決]libpq5.x86_64 15.0-42PGDG.rhel8 pgdg-common がインストールできない

libpq5.x86_64 15.0-42PGDG.rhel8 pgdg-common がインストールできません。

[環境]

# cat /etc/almalinux-release
AlmaLinux release 8.6 (Sky Tiger)

# cat /etc/yum.repos.d/pgdg-redhat-all.repo
[pgdg-common]
name=PostgreSQL common RPMs for RHEL / Rocky $releasever - $basearch
baseurl=https://download.postgresql.org/pub/repos/yum/common/redhat/rhel-$releasever-$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
repo_gpgcheck = 1

[やったこと]

# dnf check-update
Last metadata expiration check: 1:34:46 ago on Fri 21 Oct 2022 07:06:30 AM JST.

libpq5.x86_64                                         15.0-42PGDG.rhel8                                          pgdg-common

# dnf update
Last metadata expiration check: 1:34:22 ago on Fri 21 Oct 2022 07:06:30 AM JST.
Error:
 Problem: package perl-DBD-Pg-3.7.4-4.module_el8.6.0+2829+05d1a4fc.x86_64 requires libpq.so.5(RHPG_9.6)(64bit), but none of the providers can be installed
  - cannot install both libpq5-15.0-42PGDG.rhel8.x86_64 and libpq5-14.5-42PGDG.rhel8.x86_64
  - package libpq5-15.0-42PGDG.rhel8.x86_64 obsoletes libpq provided by libpq-13.5-1.el8.x86_64
  - cannot install the best update candidate for package perl-DBD-Pg-3.7.4-4.module_el8.6.0+2829+05d1a4fc.x86_64
  - cannot install the best update candidate for package libpq5-14.5-42PGDG.rhel8.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

# rpm -qa | grep perl-DBD-Pg
perl-DBD-Pg-3.7.4-4.module_el8.6.0+2829+05d1a4fc.x86_64

# yum info perl-DBD-Pg
メタデータの期限切れの最終確認: 2:11:46 時間前の 2022年10月18日 02時55分28秒 に実施しました。
インストール済みパッケージ
名前         : perl-DBD-Pg
バージョン   : 3.7.4
リリース     : 4.module_el8.6.0+2829+05d1a4fc
Arch         : x86_64
サイズ       : 567 k
ソース       : perl-DBD-Pg-3.7.4-4.module_el8.6.0+2829+05d1a4fc.src.rpm
リポジトリー : @System
repo から    : appstream
概要         : A PostgreSQL interface for perl
URL          : http://search.cpan.org/dist/DBD-Pg/
ライセンス   : GPLv2+ or Artistic
説明         : DBD::Pg is a Perl module that works with the DBI module to provide access
             : to PostgreSQL databases.

perl-DBD-Pg-3.7.4-4.module_el8.6.0+2829+05d1a4fc.x86_64にはlibpq.so.5(RHPG_9.6)(64bit)が必要だけど、インストールしようとしているlibpq5.x86_64 15.0-42PGDG.rhel8はNGなのだろうと思います。
今は、libpq5-14.5-42PGDG.rhel8.x86_64が入っています。
どうすればいいのかわかりません…
いつか、libpq5.x86_64 15.0-42PGDG.rhel8に対応した、perl-DBD-Pgがリリースされるのを待つ…でいいのでしょうか。

2022年10月14日21:00

カテゴリ: PostgreSQL

パッケージ pgpool-II-pg11-extensions-4.3.3-1.rhel8.x86_64 には pgpool-II-pcp が必要ですが、どのプロバイダーからもインストールできません

PostgreSQLを11から15にVerUPするため、pgdg-redhat-all.repoを最新のものに差し替えて、dnf updateしたところ以下のエラーが発生しました。

[root@sub0000529529 yum.repos.d]# dnf check-update
pgpool-II-pg11-extensions.x86_64                                    4.3.3-1.rhel8                                     pgdg11

[root@sub0000529529 yum.repos.d]# dnf update
エラー:
 問題: パッケージ pgpool-II-pg11-extensions-4.3.3-1.rhel8.x86_64 には pgpool-II-pcp が必要ですが、どのプロバイダーからもインストールできません
  - パッケージ pgpool-II-pg11-extensions-4.3.3-1.rhel8.x86_64 には libpcp.so.2()(64bit) が必要ですが、どのプロバイダーからもインストールできません
  - パッケージの最良アップデート候補をインストールできません pgpool-II-pg11-extensions-4.1.13-1pgdg.rhel8.x86_64
  - postgresql14-server が提供されません pgpool-II-pcp-4.3.2-1.rhel8.x86_64 に必要です
  - postgresql14-server が提供されません pgpool-II-pcp-4.3.3-1.rhel8.x86_64 に必要です
(インストール不可のパッケージをスキップするには、'--skip-broken' を追加してみてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)

https://erscape.livedoor.blog/archives/9819666.html と同じ案件。

[pgdg15]
name=PostgreSQL 15 for RHEL / Rocky $releasever - $basearch
baseurl=https://download.postgresql.org/pub/repos/yum/15/redhat/rhel-$releasever-$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
repo_gpgcheck = 1
exclude=pgpool*

[pgdg11]
name=PostgreSQL 11 for RHEL / Rocky $releasever - $basearch
baseurl=https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-$releasever-$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
repo_gpgcheck = 1
exclude=pgpool*

として、pgdgのリポジトリからpgpoolをインストールしないようにしました。

タグ：: PostgreSQLを11から15にVerUP

2022年10月14日20:30

カテゴリ: PostgreSQL

repo_gpgcheckとは

PostgreSQLを11から15にVerUPするため、pgdg-redhat-all.repoを最新のものに差し替えたら、repo_gpgcheckというパラメータが増えてました。

$ cat pgdg-redhat-all.repo.rpmnew

(中略)
[pgdg15]
name=PostgreSQL 15 for RHEL / Rocky $releasever - $basearch
baseurl=https://download.postgresql.org/pub/repos/yum/15/redhat/rhel-$releasever-$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
repo_gpgcheck = 1
(中略)

$ man yum.conf

       gpgcheck
              boolean

              Whether to perform GPG signature check on packages found in this repository.  The default is False.

              This option can only be used to strengthen the active RPM security policy set with  the  %_pkgverify_level
              macro  (see  the /usr/lib/rpm/macros file for details).  That means, if the macro is set to 'signature' or
              'all' and this option is False, it will be overridden to True during DNF runtime, and a  warning  will  be
              printed.   To  squelch  the  warning, make sure this option is True for every enabled repository, and also
              enable localpkg_gpgcheck.

DeepLの訳

このリポジトリで見つかったパッケージに対して、GPG署名チェックを行うかどうか。
デフォルトは False です。

このオプションは、%_pkgverify_level マクロで設定されたアクティブな RPM セキュリティポリシーを強化するためにのみ使用できます (詳細は /usr/lib/rpm/macros ファイルを参照してください)。マクロ (詳細は /usr/lib/rpm/macros ファイルを参照) で設定されたアクティブな RPM セキュリティポリシーの強化にのみ使用できます。
つまり、マクロが 'signature' または 'all' に設定され、このオプションが False である場合マクロが 'all' に設定され、このオプションが False の場合、DNF 実行時に True に上書きされ、警告が表示されます。が表示される。
この警告を消すには、有効なすべてのリポジトリでこのオプションが True であることを確認し、さらに localpkg_gpgcheck を有効にしてください。

www.DeepL.com/Translator（無料版）で翻訳しました。

タグ：: PostgreSQLを11から15にVerUP

2021年12月30日22:44

カテゴリ: PostgreSQL; TypeORM

[解決]TypeORMでPostgreSQLのboolean型の列からデータを取得するとWindowsとLinuxで型が違う

本件解決いたしました。
結論から書くと、LinuxのPostgreSQLのis_two_factor_authentication_enabledがtext型、WindowsのPostgreSQLのis_two_factor_authentication_enabledがboolean型にしてしまっていました。

どうしてこうなったのかというと人為ミスです。
WindowsのPostgreSQLの定義をダンプして、Docker環境のPostgreSQLに流し込む…ということをしているのですが、Docker環境のPostgreSQLに一世代前のWindowsのPostgreSQLの定義を流し込んでおり、不一致が発生していました。

TypeORMでPostgreSQLのboolean型の列からデータを取得する場合、WindowsのPostgreSQLから取得した場合とLinuxのPostgreSQLで型が違いました。

擬似コードは以下のとおりです。
[Usersテーブルの定義抜粋]

@Entity()
export class Users {
  @Column({ type: "boolean", default: false })
  @Exclude()
  is_two_factor_authentication_enabled: boolean;

[確認コード抜粋]

let usersRepository: Repository;
usersRepository = getRepository(Users);

    const userDataFromDB = await usersRepository.findOne({
      where: {
        id: testUserId,
      },
    });
    console.log(typeof userDataFromDB.is_two_factor_authentication_enabled);

[出力]
接続先がWindowsで動かしているのPostgreSQLの場合

  ● Console

    console.log
      boolean

接続先がLinuxで動かしているのPostgreSQLの場合

  ● Console

    console.log
      string

なぜ違うのでしょうか…booleanで返ってきて欲しい…

2021年08月15日10:15

カテゴリ: PostgreSQL; munin

muninのpluginであるpostgres_querylength_において、「Oldest query」の項目が着々と増える事象が発生する

muninのpluginであるpostgres_querylength_において、「Oldest query」の項目が着々と増える事象が発生しています。

契機は、おそらく、PostgreSQLのVerを11.12から11.13にあげたとき…だと思っています。何をもって「Oldest query」を判定しているかについて、pluginの内容を確認したところ以下のクエリの結果でした。

SELECT 'query',COALESCE(max(extract(epoch FROM CURRENT_TIMESTAMP-query_start)),0) FROM pg_stat_activity WHERE state NOT LIKE 'idle%';

このクエリを

SELECT *,COALESCE(extract(epoch FROM CURRENT_TIMESTAMP-query_start),0) FROM pg_stat_activity WHERE state NOT LIKE 'idle%' ;

とかえて実行してみたところ、

ap2=# SELECT pid,usename,application_name,query_start,wait_event_type,wait_event,state,query,backend_type,COALESCE(extract(epoch FROM CURRENT_TIMESTAMP-query_start),0) FROM pg_stat_activity WHERE state NOT LIKE 'idle%' ;
-[ RECORD 2 ]----+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid              | 1171010
usename          | replication_user
application_name | walreceiver
query_start      | 2021-08-15 09:43:10.596396+09
wait_event_type  | Activity
wait_event       | WalSenderMain
state            | active
query            | START_REPLICATION SLOT "replication_slot_for_gmo" C7/F3000000 TIMELINE 26
backend_type     | walsender
coalesce         | 740.883447
-[ RECORD 3 ]----+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid              | 1171187
usename          | replication_user
application_name | sby
query_start      | 2021-08-15 09:44:00.86581+09
wait_event_type  | Activity
wait_event       | WalSenderMain
state            | active
query            | START_REPLICATION SLOT "replication_slot_for_local" C7/F3000000 TIMELINE 26
backend_type     | walsender
coalesce         | 690.614033

が返ってきました。
レプリケーションをするための「START_REPLICATION SLOT」ではじまるクエリが終わらないので、このクエリを「Oldest query」として、「CURRENT_TIMESTAMP-query_start」の値をmuninが表示する…ということでした。

今までは「Oldest query」は表示されていなかったので、START_REPLICATION SLOTではじまるクエリは実行されたらすぐに処理を終えて終了していたのだと思うのですが、何かを契機に「START_REPLICATION SLOT」が終了しなくなったのだと思います。

レプリケーションができていないわけではなく、ちゃんとレプリケーションできているので、今のところ実害はないように見えます。

$ psql -p 5432 -U postgres -c "select client_addr,state,sync_state from pg_stat_replication;"
  client_addr   |   state   | sync_state
----------------+-----------+------------
 ***.***.***.***| streaming | async
 ***.***.***.***| streaming | async
(2 rows)

ただ、マニュアルを見ると「START_REPLICATION SLOT」は

サーバに対して、XXX/XXXWAL時点から、論理的レプリケーションのWALストリームを開始するよう指示します。
例えば、要求されたWALがすでに回収された場合、サーバはエラーを返します。
サーバが、例えば、要求されたWALセクションがすでに回収されている場合、エラーを返すことがありえます。
成功時サーバはCopyBothResponseメッセージで応答し、フロントエンドに対するWALストリームを開始します。

とあるので、なんらかの応答が返ってきてクエリは終了するはず…だと思っています。

slotが悪さをしている可能性を疑い

SELECT pg_drop_replication_slot('replication_slot_for_local');

をして、再度、pg_create_physical_replication_slotしてみましたが、状況は変わりませんでした。

何かご存知の方がいらっゃいましたら、お知らせいただけると幸いです。

2021年08月14日16:28

カテゴリ: PostgreSQL

problem with installed package llvm-devel-10.0.1-3PGDG.el8.x86_64

CentOS8において、dnf updateしようとした際に、以下のエラーでupdateができませんでした。

[root@sub0000529529 ap2]# dnf update postgresql11-llvmjit
メタデータの期限切れの最終確認: 0:05:58 時間前の 2021年08月14日 07時49分58秒 に実施しました。
エラー:
 問題: problem with installed package llvm-devel-10.0.1-3PGDG.el8.x86_64
  - package llvm-devel-10.0.1-3PGDG.el8.x86_64 requires llvm-libs(x86-64) = 10.0.1-3PGDG.el8, but none of the providers can be installed
  - package llvm-devel-10.0.1-3PGDG.el8.x86_64 requires libLLVM-10.so()(64bit), but none of the providers can be installed
  - package llvm-devel-10.0.1-3PGDG.el8.x86_64 requires libLLVM-10.so(LLVM_10)(64bit), but none of the providers can be installed
  - cannot install both llvm-libs-11.0.0-2.el8.x86_64 and llvm-libs-10.0.1-3PGDG.el8.x86_64
  - package llvm-devel-11.0.0-2.el8.x86_64 requires llvm-test(x86-64) = 11.0.0-2.el8, but none of the providers can be installed
  - package postgresql11-llvmjit-11.13-1PGDG.rhel8.x86_64 requires libLLVM-11.so()(64bit), but none of the providers can be installed
  - package postgresql11-llvmjit-11.13-1PGDG.rhel8.x86_64 requires libLLVM-11.so(LLVM_11)(64bit), but none of the providers can be installed
  - package llvm-test-11.0.0-2.el8.x86_64 requires python3-lit, but none of the providers can be installed
  - cannot install the best update candidate for package postgresql11-llvmjit-11.12-1PGDG.rhel8.x86_64
  - package llvm-libs-11.0.0-2.module_el8.4.0+587+5187cac0.x86_64 is filtered out by modular filtering
  - package python3-lit-0.11.0-1.module_el8.4.0+587+5187cac0.noarch is filtered out by modular filtering
(競合するパッケージを置き換えるには、コマンドラインに '--allowerasing' を追加してみてください または、'--skip-broken' を追加して、インストール不可のパッケージをスキップしてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)

結論から書くと、2021/08/14時点で以下のパッケージはVerをあわせることができないです。
postgresql11-devel
postgresql11-test
postgresql11-llvmjit.x86_64

 postgresql11-devel             x86_64             11.13-1PGDG.rhel8             @pgdg11                               10 M
 postgresql11-test              x86_64             11.13-1PGDG.rhel8             @pgdg11                               11 M

は、

llvm                           x86_64             10.0.1-3PGDG.el8              @pgdg-centos8-sysupdates              14 M

が必要ですが、postgresql11-llvmjitは

[root@sub0000529529 ap2]# dnf install postgresql11-llvmjit
メタデータの期限切れの最終確認: 0:11:01 時間前の 2021年08月14日 07時49分58秒 に実施しました。
依存関係が解決しました。
============================================================================================================================
 パッケージ                      アーキテクチャー  バージョン                      リポジトリー                       サイズ
============================================================================================================================
インストール:
 postgresql11-llvmjit            x86_64            11.13-1PGDG.rhel8               pgdg11                             9.2 M
依存関係のインストール:
 llvm                            x86_64            11.0.0-2.el8                    pgdg-centos8-sysupdates             12 M
 llvm-libs                       x86_64            11.0.0-2.el8                    pgdg-centos8-sysupdates             21 M

のように、postgresql11-devel / postgresql11-testとpostgresql11-llvmjitで必要なllvmのVerが違います。

[root@sub0000529529 ap2]# dnf install postgresql11-test postgresql11-devel
メタデータの期限切れの最終確認: 0:11:48 時間前の 2021年08月14日 07時49分58秒 に実施しました。
依存関係が解決しました。
============================================================================================================================
 パッケージ                      アーキテクチャー  バージョン                      リポジトリー                       サイズ
============================================================================================================================
インストール:
 postgresql11-devel              x86_64            11.13-1PGDG.rhel8               pgdg11                             2.1 M
 postgresql11-test               x86_64            11.13-1PGDG.rhel8               pgdg11                             1.8 M
依存関係のインストール:
 clang                           x86_64            10.0.1-1.el8                    pgdg-centos8-sysupdates             74 k
 clang-devel                     x86_64            10.0.1-1.el8                    pgdg-centos8-sysupdates            2.0 M
 clang-libs                      x86_64            10.0.1-1.el8                    pgdg-centos8-sysupdates             25 M
 clang-tools-extra               x86_64            10.0.1-1.el8                    pgdg-centos8-sysupdates             13 M
 libicu65                        x86_64            65.1-1.el8.remi                 remi-safe                          9.3 M
 libicu65-devel                  x86_64            65.1-1.el8.remi                 remi                               979 k
 llvm-devel                      x86_64            10.0.1-3PGDG.el8                pgdg-centos8-sysupdates            3.1 M
ダウングレード:
 llvm                            x86_64            10.0.1-3PGDG.el8                pgdg-centos8-sysupdates            4.5 M
 llvm-libs                       x86_64            10.0.1-3PGDG.el8                pgdg-centos8-sysupdates             20 M
 postgresql11-llvmjit            x86_64            11.12-1PGDG.rhel8               pgdg11                             9.2 M

以上の結果から、postgresql11-devel / postgresql11-testは11.13-1、postgresql11-llvmjitは11.12-1であればOKですので、どちらのパッケージも必要な場合は、postgresql11-llvmjitは11.12-1を使うことになるのかなと思います。

ErogameScapeでは、postgresql11-devel / postgresql11-testをインストールしていたのですが、そもそも必要なかったので…、この機会にpostgresql11-devel / postgresql11-testをremoveしました。
そして、postgresql11-llvmjitをインストールしているのに、有効にしていなかった(jitはPostgreSQLはデフォルトでoffでした…)ので、onにしてみました。
もしかしたら性能が改善するかもしれません。