PostgreSQL

ある日突然SQLが遅くなった(サロゲートキーがある中間テーブルに複数列インデックスを作成していなかった)

ある日、以下の SQL を実行した際、campaign_game テーブルに campaign = '7588' に該当する行がない場合、約 300ms もの時間がかかる現象 が発生しました。
SELECT
    cg.game,
    cg.content,
    cg.url,
    g.gamename,
    g.median
FROM
    campaign_game cg
    INNER JOIN gamelist g
    ON cg.game = g.id
WHERE
    cg.campaign = '7588'
ORDER BY
    g.median DESC,
    g.count2 DESC,
    g.id
LIMIT 1;
campaign_game テーブルは、あるキャンペーンにどのゲームが紐づいているかを格納する中間テーブルです。
テーブルの定義は以下のとおりです。
# \d campaign_game
                             Table "public.campaign_game"
  Column		|  Type   | Collation | Nullable |                  Default
-------------------+---------+------------+------------+-------------------------------------------
 id			| integer |                | not null   | nextval('campaign_game_id_seq'::regclass)
 campaign	| integer |                | not null   |
 game		| integer |                | not null   |
 content		| text      |                |                |
 url			| text      |                |                |
Indexes:
    "campaign_game_pkey" PRIMARY KEY, btree (id)
    "campaign_game_campaign_index" btree (campaign)
    "campaign_game_game_index" btree (game)
Foreign-key constraints:
    "campaign_game_campaign_fkey" FOREIGN KEY (campaign) REFERENCES campaignlist(id) ON UPDATE CASCADE ON DELETE CASCADE
    "campaign_game_game_fkey" FOREIGN KEY (game) REFERENCES gamelist(id) ON UPDATE CASCADE ON DELETE CASCADE
結論として、campaign_game テーブルに複数列インデックス
CREATE INDEX campaign_game_campaign_game_index ON campaign_game (campaign, game);
を作成していなかったことが原因でした。

事象の分析

gamelist テーブルはゲームの情報を格納するテーブルです。
今回のクエリは campaign = 7588 のキャンペーン対象のゲームを取得するものですが、campaign_game には campaign = 7588 のデータが存在しません
したがって、campaign_gamecampaign 列を campaign_game_campaign_index で検索すれば、すぐに 0 行であると判明し、速やかに応答が返るはずでした。

しかし、事象発生時の EXPLAIN ANALYZE の出力は以下のようになっていました。

 Limit  (cost=868.30..1355.74 rows=1 width=164) (actual time=327.409..327.409 rows=0 loops=1)
   ->  Incremental Sort  (cost=868.30..87631.79 rows=178 width=164) (actual time=327.408..327.408 rows=0 loops=1)
         Sort Key: g.median DESC, g.count2 DESC, cg.game
         Presorted Key: g.median
         Full-sort Groups: 1  Sort Method: quicksort  Average Memory: 25kB  Peak Memory: 25kB
         ->  Nested Loop  (cost=0.71..87625.98 rows=178 width=164) (actual time=327.404..327.405 rows=0 loops=1)
               ->  Index Scan Backward using tokuten_index on gamelist g  (cost=0.29..15344.82 rows=32376 width=107) (actual time=0.007..24.140 rows=32376 loops=1)
               ->  Index Scan using campaign_game_game_index on campaign_game cg  (cost=0.42..2.22 rows=1 width=57) (actual time=0.009..0.009 rows=0 loops=32376)
                     Index Cond: (game = g.id)
                     Filter: (campaign = 7588)
                     Rows Removed by Filter: 19
 Planning Time: 0.230 ms
 Execution Time: 327.437 ms
この結果を分析したところ、以下の問題点が判明しました。

campaign_game 側のフィルタが結合後に実行されている
Index Scan using campaign_game_game_index on campaign_game cg
Index Cond: (game = g.id)
Filter: (campaign = 7588)
gamelist32376 行それぞれに対して、campaign_game を結合した後に campaign = 7588 のフィルタを適用しているため、無駄なループ (loops=32376) が発生。
このため、本来 campaign = 7588 の行がないとすぐに終了すべきクエリが、すべての gamelist のデータを走査してしまい、遅くなっていました

対応策

campaign_game テーブルに (campaign, game) の複合インデックスを作成。

CREATE INDEX idx_campaign_game ON campaign_game (campaign, game);
この結果、EXPLAIN ANALYZE は以下のように改善されました。

 Limit  (cost=562.42..879.79 rows=1 width=164) (actual time=52.224..52.225 rows=0 loops=1)
   ->  Incremental Sort  (cost=562.42..56737.69 rows=177 width=164) (actual time=52.224..52.224 rows=0 loops=1)
         Sort Key: g.median DESC, g.count2 DESC, cg.game
         Presorted Key: g.median
         Full-sort Groups: 1  Sort Method: quicksort  Average Memory: 25kB  Peak Memory: 25kB
         ->  Nested Loop  (cost=0.71..56731.90 rows=177 width=164) (actual time=52.220..52.220 rows=0 loops=1)
               ->  Index Scan Backward using tokuten_index on gamelist g  (cost=0.29..15344.82 rows=32376 width=107) (actual
 time=0.006..19.325 rows=32381 loops=1)
               ->  Index Scan using campaign_game_campaign_game_index on campaign_game cg  (cost=0.42..1.27 rows=1 width=57)
 (actual time=0.001..0.001 rows=0 loops=32381)
                     Index Cond: ((campaign = 7588) AND (game = g.id))
 Planning Time: 0.425 ms
 Execution Time: 52.252 ms
campaign_gamecampaign = 7588 で事前にフィルタリングされ、Nested Loop の無駄な繰り返しがなくなりました。

教訓

サロゲートキーのある中間テーブルでは、複数列インデックスの作成を考慮する

補足

今回のSQLは、ある日突然遅くなりました。つまり、それ以前は素早い応答を返していたはずです。
そこで、作成した campaign_game_campaign_game_index を削除し、SQL を実行してみました。

 Limit  (cost=27.87..107.02 rows=1 width=160) (actual time=0.010..0.011 rows=0 loops=1)
   ->  Merge Join  (cost=27.87..14038.89 rows=177 width=160) (actual time=0.010..0.010 rows=0 loops=1)
         Merge Cond: (g.id = cg.game)
         ->  Index Scan using gamelist_pkey on gamelist g  (cost=0.29..14296.29 rows=32376 width=103) (actual time=0.004..0.004 rows=1 loops=1)
         ->  Sort  (cost=26.25..26.69 rows=177 width=57) (actual time=0.005..0.005 rows=0 loops=1)
               Sort Key: cg.game
               Sort Method: quicksort  Memory: 25kB
               ->  Index Scan using campaign_game_campaign_index on campaign_game cg  (cost=0.42..19.64 rows=177 width=57) (actual time=0.004..0.004 rows=0 loops=1)
                     Index Cond: (campaign = 7588)
 Planning Time: 0.194 ms
 Execution Time: 0.027 ms

実行結果を見ると、campaign_game テーブルを campaign = 7588 で絞り込んでいるため、爆速で結果が返ってきています。
もともとこのクエリで動いていたのに、実行計画が変わったことでクエリの処理が遅くなったのではないかと考えられます。

その後、再び campaign_game_campaign_game_index を追加し、削除してみたところ、上記の実行計画にはならなくなりました。
今回の案件は campaign_game_campaign_game_index を追加することで対応完了とします。

PostgreSQLで実行中のトランザクションを強制的に解放する

FANZA同人の男性向け作品一覧の大幅割引作品の検索サイトは、以下のようなSQLでデータを流し込んでいます。
PREPARE fanza_doujin_sales_plan (
    text
  , text
  , integer
  , text
  , integer
  , integer
  , text
  , text
  , integer
  , timestamp with time zone
  , date
  , integer
) AS
INSERT INTO fanza_doujin_sales (
    cid
  , title
  , maker_id
  , maker_name
  , price
  , discount_rate
  , img
  , genre
  , number_of_sales
  , campaign_due_date
  , delivery_start_date
  , number_of_pages
) VALUES ( $1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12 )
ON CONFLICT (cid, campaign_due_date)
DO UPDATE SET price = $5, discount_rate = $6
RETURNING cid, title, (xmax = 0) AS inserted;
;
EXECUTE fanza_doujin_sales_plan(
    'd_243614'
  , '使用済みの姪っ子を俺の女に染めるまで'
  , 75096
  , 'あまいちご'
  , 192
  , 75
  , 'https://doujin-assets.dmm.co.jp/digital/comic/d_243614/d_243614pl.jpg'
  , 'コミック'
  , 85465
  , '2023/10/16'
  , '2022/09/30'
  , 24
);
ある日、BEGINを実行した後に上記SQLを流し込んでいる最中にターミナルのセッションが切れてしまいました。
そこで新たにターミナルを立ち上げて上記SQLを流し込もうとしたところトランザクションがロールバックされていないため、テーブルにロックが入ってSQLが実行待ちになってしまいました。
あー、ロックを強制的に外さないと駄目かなあ…、そもそもロックの確認方法を忘れている…といろいろ調べているうちに自然にロックが解除され(セッションが切れてから一定時間立つとロールバックされるのかな…)実行待ち状態は解除されました。

ロックの確認とロックしているプロセスの解放方法の確認に時間がかかったのでメモしておきます。

ロックの確認方法
SELECT
    l.relation::regclass,
    l.locktype,
    l.mode,
    l.granted,
    a.pid,
    a.query
FROM
    pg_locks l
JOIN
    pg_stat_activity a
ON
    l.pid = a.pid
WHERE
    l.relation = 'fanza_doujin_sales'::regclass;
ap2=# SELECT
    l.relation::regclass,
    l.locktype,
    l.mode,
    l.granted,
    a.pid,
    a.query
FROM
    pg_locks l
JOIN
    pg_stat_activity a
ON
    l.pid = a.pid
WHERE
    l.relation = 'fanza_doujin_sales'::regclass;
      relation      | locktype |       mode       | granted |   pid   |                                    query
--------------------+----------+------------------+---------+---------+-----------------------------------------------------------------------------
 fanza_doujin_sales | relation | RowExclusiveLock | t       | 3190875 | EXECUTE fanza_doujin_sales_plan(                                           +
                    |          |                  |         |         |     'd_243614'                                                             +
                    |          |                  |         |         |   , '使用済みの姪っ子を俺の女に染めるまで'                                 +
                    |          |                  |         |         |   , 75096                                                                  +
                    |          |                  |         |         |   , 'あまいちご'                                                           +
                    |          |                  |         |         |   , 192                                                                    +
                    |          |                  |         |         |   , 75                                                                     +
                    |          |                  |         |         |   , 'https://doujin-assets.dmm.co.jp/digital/comic/d_243614/d_243614pl.jpg'+
                    |          |                  |         |         |   , 'コミック'                                                             +
                    |          |                  |         |         |   , 85465                                                                  +
                    |          |                  |         |         |   , '2023/10/16'                                                           +
                    |          |                  |         |         |   , '2022/09/30'                                                           +
                    |          |                  |         |         |   , 24                                                                     +
                    |          |                  |         |         | );
(1 row)
プロセスの強制終了
ap2=# select pg_terminate_backend(3190875) ;
 pg_terminate_backend
----------------------
 t
(1 row)

ap2=# SELECT
    l.relation::regclass,
    l.locktype,
    l.mode,
    l.granted,
    a.pid,
    a.query
FROM
    pg_locks l
JOIN
    pg_stat_activity a
ON
    l.pid = a.pid
WHERE
    l.relation = 'fanza_doujin_sales'::regclass;
 relation | locktype | mode | granted | pid | query
----------+----------+------+---------+-----+-------
(0 rows)
pg_cancel_backendだとプロセスを殺すことができませんでした。
ap2=# select pg_cancel_backend(3191875) ;
 pg_cancel_backend
-------------------
 t
(1 row)

ap2=# SELECT
    l.relation::regclass,
    l.locktype,
    l.mode,
    l.granted,
    a.pid,
    a.query
FROM
    pg_locks l
JOIN
    pg_stat_activity a
ON
    l.pid = a.pid
WHERE
    l.relation = 'fanza_doujin_sales'::regclass;
      relation      | locktype |       mode       | granted |   pid   |                                    query
--------------------+----------+------------------+---------+---------+-----------------------------------------------------------------------------
 fanza_doujin_sales | relation | RowExclusiveLock | t       | 3191875 | EXECUTE fanza_doujin_sales_plan(                                           +
                    |          |                  |         |         |     'd_243614'                                                             +
                    |          |                  |         |         |   , '使用済みの姪っ子を俺の女に染めるまで'                                 +
                    |          |                  |         |         |   , 75096                                                                  +
                    |          |                  |         |         |   , 'あまいちご'                                                           +
                    |          |                  |         |         |   , 192                                                                    +
                    |          |                  |         |         |   , 75                                                                     +
                    |          |                  |         |         |   , 'https://doujin-assets.dmm.co.jp/digital/comic/d_243614/d_243614pl.jpg'+
                    |          |                  |         |         |   , 'コミック'                                                             +
                    |          |                  |         |         |   , 85465                                                                  +
                    |          |                  |         |         |   , '2023/10/16'                                                           +
                    |          |                  |         |         |   , '2022/09/30'                                                           +
                    |          |                  |         |         |   , 24                                                                     +
                    |          |                  |         |         | );
(1 row)

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

ドキュメント

.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


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 検証レポート

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


[解決]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がリリースされるのを待つ…でいいのでしょうか。



パッケージ 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をインストールしないようにしました。

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(無料版)で翻訳しました。

[解決]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で返ってきて欲しい…
記事検索