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ドキュメント
PostgreSQL
pg_basebackupコマンドに--write-recovery-confオプションをつけて実行すると、postgresql.auto.confが生成されます。
その中身は
pg_basebackupをするためのユーザーがバックアップ元に接続するためにパスワードが必要な場合、そのパスワードを.pgpassに書くことができます。
.pgpassの書式は、34.16. パスワードファイルの通りです。
具体的には
また、.pgpassの権限は600でなければなりません。
600でないとログにエラーが出力されます。
その中身は
# 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コマンドの進捗をバックアップ元でも確認できるようになりました。
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)で起動しませんでした。
[postgres@localhost data]$ touch standby.signalPostgreSQL 12の新機能をいくつか試してみたの「recovery.confのpostgresql.confへの統合」を拝見したところ、
[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: サーバーを昇格できません; サーバーはスタンバイモードではありません
$ 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-14.5-42PGDG.rhel8.x86_64が入っています。
どうすればいいのかわかりません…
いつか、libpq5.x86_64 15.0-42PGDG.rhel8に対応した、perl-DBD-Pgがリリースされるのを待つ…でいいのでしょうか。
[環境]
# 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
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 pgdg11https://erscape.livedoor.blog/archives/9819666.html と同じ案件。
[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' を追加して、最適候補のパッケージのみを使用しないでください)
[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するため、pgdg-redhat-all.repoを最新のものに差し替えたら、repo_gpgcheckというパラメータが増えてました。
DeepLの訳
$ 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(無料版)で翻訳しました。
2021年12月30日22:44
本件解決いたしました。
結論から書くと、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テーブルの定義抜粋]
接続先がWindowsで動かしているのPostgreSQLの場合
結論から書くと、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
契機は、おそらく、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が悪さをしている可能性を疑い
slotが悪さをしている可能性を疑い
SELECT pg_drop_replication_slot('replication_slot_for_local');をして、再度、pg_create_physical_replication_slotしてみましたが、状況は変わりませんでした。
何かご存知の方がいらっゃいましたら、お知らせいただけると幸いです。
CentOS8において、dnf updateしようとした際に、以下のエラーでupdateができませんでした。
postgresql11-devel
postgresql11-test
postgresql11-llvmjit.x86_64
ErogameScapeでは、postgresql11-devel / postgresql11-testをインストールしていたのですが、そもそも必要なかったので…、この機会にpostgresql11-devel / postgresql11-testをremoveしました。
そして、postgresql11-llvmjitをインストールしているのに、有効にしていなかった(jitはPostgreSQLはデフォルトでoffでした…)ので、onにしてみました。
もしかしたら性能が改善するかもしれません。
[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にしてみました。
もしかしたら性能が改善するかもしれません。
記事検索
人気記事
最新記事
月別アーカイブ
カテゴリ別アーカイブ
RSS