Q&A
毎日特定の時間にプログラムが走るのなら、cronとatでスケジュールされているのだと思います。cronに関連する設定ファイルを確認しては如何ですか？
当方linux環境でPostgresSqlを使用しています。
原因もこれがなんなのかも不明で申し訳ないのですが、毎日特定の時間にプロセスがはしり？ACCESS SHARE LOCKが走っているようで、原因に心当たりのある方がいらっしゃいましたらご教示願えましたら幸いです。
ちなみに下記のクエリを実行しているプログラムを探したのですが見当たりませんでした・・・
select * from pg_stat_activity; 【上記を実行したところ、プロセス上で流れていると思われるクエリ↓】 SELECT typinput='array_in'::regproc, typtype FROM pg_catalog.pg_type LEFT JOIN (select ns.oid as nspoid, ns.nspname, r.r from pg_namespace as ns join ( select s.r, (current_schemas(false))[s.r ] as nspname from generate_series(1, array_upper(current_schemas(false), 1)) as s(r) ) as r using ( nspname ) ) as sp ON sp.nspoid = typnamespace WHERE typname = $1 ORDER BY sp.r, pg_type.oid DESC LIMIT 1 【テーブルのロック状態】 SELECT l.pid, db.datname, c.relname, l.locktype, l.mode FROM pg_locks l LEFT JOIN pg_class c ON l.relation=c.relfilenode LEFT JOIN pg_database db ON l.database = db.oid ORDER BY l.pid; pid | granted | datname | locktype | relation | relation | transactionid | mode ------+---------+---------+------------+----------+----------------------------+---------------+----------------- 1095 | t | testdb | relation | 2684 | pg_namespace_nspname_index | | AccessShareLock 1095 | t | testdb | relation | 2704 | pg_type_typname_nsp_index | | AccessShareLock 1095 | t | testdb | relation | 2703 | pg_type_oid_index | | AccessShareLock 1095 | t | testdb | relation | 2615 | pg_namespace | | AccessShareLock 1095 | t | testdb | relation | 1247 | pg_type | | AccessShareLock 1095 | t | testdb | relation | 122973 | pk_mst_____test | | AccessShareLock 1095 | t | testdb | relation | 123195 | pk_trn_receipt_base | | AccessShareLock 1095 | t | testdb | relation | 121979 | mst_____test | | AccessShareLock 1095 | t | testdb | relation | 122547 | trn____test_test | | AccessShareLock 1095 | t | testdb | relation | 123075 | pk_mst__test | | AccessShareLock 1095 | t | | virtualxid | | | | ExclusiveLock 1095 | t | testdb | relation | 122220 | mst__test | | AccessShareLock 1095 | t | testdb | relation | 2685 | pg_namespace_oid_index | | AccessShareLock 1342 | t | testdb | relation | 122220 | mst__test | | AccessShareLock 1342 | t | testdb | relation | 2684 | pg_namespace_nspname_index | | AccessShareLock 1342 | t | testdb | relation | 2704 | pg_type_typname_nsp_index | | AccessShareLock 1342 | t | testdb | relation | 2703 | pg_type_oid_index | | AccessShareLock 1342 | t | testdb | relation | 2615 | pg_namespace | | AccessShareLock 1342 | t | testdb | relation | 1247 | pg_type | | AccessShareLock 1342 | t | testdb | relation | 122973 | pk_mst_____test | | AccessShareLock 1342 | t | testdb | relation | 123195 | pk_trn_receipt_base | | AccessShareLock 1342 | t | testdb | relation | 121979 | mst_____test | | AccessShareLock 1342 | t | testdb | relation | 122547 | trn_receipt_base | | AccessShareLock 1342 | t | testdb | relation | 123075 | pk_mst__test | | AccessShareLock 1342 | t | | virtualxid | | | | ExclusiveLock 1342 | t | testdb | relation | 2685 | pg_namespace_oid_index | | AccessShareLock 1627 | t | testdb | relation | 2704 | pg_type_typname_nsp_index | | AccessShareLock 1627 | t | testdb | relation | 2703 | pg_type_oid_index | | AccessShareLock 1627 | t | testdb | relation | 2615 | pg_namespace | | AccessShareLock 1627 | t | testdb | relation | 1247 | pg_type | | AccessShareLock 1627 | t | testdb | relation | 122973 | pk_mst_____test | | AccessShareLock 1627 | t | testdb | relation | 123195 | pk_trn_receipt_base | | AccessShareLock 1627 | t | testdb | relation | 121979 | mst_____test | | AccessShareLock 1627 | t | testdb | relation | 122547 | trn_receipt_base | | AccessShareLock 1627 | t | testdb | relation | 123075 | pk_mst__test | | AccessShareLock 1627 | t | | virtualxid | | | | ExclusiveLock 1627 | t | testdb | relation | 122220 | mst__test | | AccessShareLock 1627 | t | testdb | relation | 2685 | pg_namespace_oid_index | | AccessShareLock 1627 | t | testdb | relation | 2684 | pg_namespace_nspname_index | | AccessShareLock
情報が少なく申し訳ございません、なにか他に確認すべきこと等ございましたら併せてコメント頂けませんでしょうか。
何卒宜しくお願い致します。
アドバイスありがとうございます！
crontab -l とatqを実行したところファイルがまっさらなので、特にジョブは設定されていないようです。
また、念のためanacron内のファイルやcron.dのファイルも確認しましたが、そのような記述も見受けられず。。。
プロセスのuserがpostgresになっていたので、crontab -u postgres -lも実行してみましたがジョブの登録はありませんでした。。。
でも$が使用されているということは何らかのshの可能性が高いですよね、草の根作戦で探してみます。
sudo /var/log/cron
の結果はどうでしょう。
cronのログです。
回答1件
0
ベストアンサー
root権限で、「atq」や「crontab -l」で何か登録されていないか確認してみてください。
また、それらで実行されているものならば、/var/spool/mail/に、実行ユーザー名で標準出力がファイルとして残っているかもしれません。
投稿2016/08/10 00:45
総合スコア1038
アドバイスありがとうございます！
コマンドは両方実行してみましたが、特に設定されているものはないように見えました。
また、/var/spool/mail/のディレクトリのユーザーファイルも空でした。。。
そうすると、外部からクエリが発行されているのかもしれません。PostgreSQLにリモート接続しているのか、sshでリモートでシェルを実行しているのか。。
PostgreSQLのリモート接続は、pg_hba.confに設定がありますので、そちらを確認して見てください。
また、クエリの実行ログを確認すると良いかもしれません。こちらはpostgresql.confで設定ができます。
結局直接的な原因はわからなかったのですが、どうもsessionをクローズしていなかったため（コネクションプールをする際にはこれが正しいと思っていた）
処理でエラーが起きた際にbeginの状態でプロセスが残るために発生していたようです・・・質問がそもそも見当違いで申し訳ございません
実行ログを参考に判明したので、ベストアンサーにさせていただきます。
あなたの回答
tips
プレビュー
