【EDB Postgres／PostgreSQL】うるう秒（閏秒）の対応

うるう秒（閏秒）とは、世界時UT1に対して協定世界時(UTC)を±0.9秒以内に保つよう、1秒単位で追加／削除される秒です。次回のうるう秒の調整は平成29年（2017年）1月1日（日）に行われ、2017/01/01 08:59:60が挿入されることで元旦が1秒長くなります。

弊社の過去のお問い合わせ履歴を確認しますと、うるう秒については実施の2ヶ月前～直前に対応の必要性についてのお問い合わせが増加する傾向があります。そこで、今回はうるう秒について紹介します。

EDB Postgres／PostgreSQLでは、うるう秒によってデータベースの動作に問題が発生することはないため、データベース側での事前の準備は必要ありません。しかし、うるう秒（2017/01/01 08:59:60）を"2017/01/01 09:00:00"として扱うため、ユーザ／アプリケーションが実行する処理によっては考慮が必要なケースがあります。

以下のような処理を行う可能性がないか事前にご確認いただき、必要に応じてアプリケーションの改修などをご検討ください。

"2017/01/01 08:59:60"は、"2017/01/01 09:00:00"と扱われるため、PITRの時間に1秒のずれが生じる可能性があります。

EDB Postgres／PostgreSQLのTIME型とTIMESTAMP型では、アプリケーションから現在時刻として"2017/01/01 08:59:60"がINSERTされてもエラーにはなりません。ただし、"2017/01/01 08:59:60"は"2017/01/01 09:00:00"と扱われます。

 postgres=# SELECT '2017/01/01 08:59:60.00'::time;
    time
 ----------
  09:00:00
 (1 row)
 

 postgres=# select '2017/01/01 08:59:60'::timestamp;
       timestamp
 ---------------------
  2017-01-01 09:00:00
 (1 row) 

この動作から、以下のようにミリ秒レベルでの逆進が発生しうるため、業務やアプリケーションで問題が無いかご確認ください。

 postgres=# select '2017-01-01 8:59:60.99'::time;
     time
 -------------
  09:00:00.99
 (1 row)
 

 postgres=# select '2017-01-01 9:00:00.10'::time;
     time
 ------------
  09:00:00.1
 (1 row) 

OSがうるう秒をサポートしていない場合は、システム時刻が実際の時刻より1秒進むため時刻調整が必要です。時刻調整の方法としては、時刻を瞬間的に戻すStep方式と、時刻の進みを遅くすることで徐々に時刻を合わせるSlew方式があります。

システム時刻をStep方式で合わせる場合は時刻が逆進することになりますが、EDB Postgres／PostgreSQLとしては時間が戻ることは想定されていないため、意図しない動作を行う可能性があります。

EDB Postgres／PostgreSQLではデータの一貫性は連番のトランザクションID（XID）によって保証されていますが、上述のように時刻を戻す際には十分な注意が必要です。

うるう秒に限らず、大幅にシステム時刻がずれていないのであれば、時刻調整はStep方式ではなくSlew方式で行うことを推奨します。

OSがうるう秒に対応しているかや、時刻調整の詳細についてはご利用のOSベンダーにご確認ください。

冒頭でお伝えしたとおり、次回は平成29年（2017年）の元旦にうるう秒の調整が行われます。基本的にEDB Postgres／PostgreSQLでは、うるう秒による通常の運用に対する影響はありませんが、今回ご紹介したように影響が及ぶケースもあります。そのため、事前にOSがうるう秒をサポートしているかや、時刻合わせの方法などを確認しておきましょう。