PostgreSQL

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で返ってきて欲しい…

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

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

Screenshot_1
契機は、おそらく、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してみましたが、状況は変わりませんでした。

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