この見逃しは、ダンプのリストアや pg_upgrade実行で権限の無いユーザがスーパーユーザ権限を得るようにする攻撃を可能にしていました。(CVE-2018-16850)

これまでは、子インデックスは常にデフォルトテーブルスペースに作られていました。

ハッシュキーに NULL値を伴う外側リレーションの行が、結合結果から抜け落ちていました。本障害のため enable_parallel_hash = on のときに、誤った問い合わせ結果が返る可能性がありました。

以下のような奇妙な動作が発生していました。

（enum_range関数は配列 '{e,f,g}' を返すので '{a,b,c,d,e,f,g}' が正しい結果）
db=# CREATE TYPE typ_efg AS ENUM ('e', 'f', 'g');
db=# SELECT
       CASE 'foo'::text WHEN 'foo'
         THEN ARRAY['a', 'b', 'c', 'd'] || enum_range(NULL::typ_efg)::text[]
         ELSE ARRAY['x', 'y']
       END;
         array
-----------------------
 {a,b,c,d,foo,foo,foo}
(1 row)

本障害により、最近に追加された列をもつテーブルの制約トリガ動作でクラッシュをひき起こすことが知られています。また、その他の症状を示す可能性もあります。

（知られている障害発生パターン）
db=# CREATE TABLE leader (a int PRIMARY KEY, b int);
db=# CREATE TABLE follower (a int REFERENCES leader ON DELETE CASCADE, b int);
db=# INSERT INTO leader VALUES (1, 1), (2, 2);
db=# ALTER TABLE leader ADD c int;
db=# ALTER TABLE leader DROP c;
db=# DELETE FROM leader;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

CALLでそのような引数をもつプロシージャを実行するときに、エラーが発生する動作が報告されていました。

STRICTな集約とは NULLを処理対象から除外する動作をするものです。ORDER BY を付与したときこの動作が働きませんでした。

（1 が返るのが正しいが、NULLが返っていた）
 db=# SELECT min(x ORDER BY y) FROM (VALUES(1, NULL)) AS d(x,y);
  min
 -----
 
 (1 row)

これはバージョン11から登場した最適化機能ですが、クラッシュをひき起こすとがあり、ひとまず無効化されました。

クラッシュをひき起こすことがありました。理想的にはこのような使い方も可能とすべきですが当面は禁止とされました。トリガ駆動時に以下のようなエラーが出るようになります。

ERROR:  cannot ALTER TABLE "..." because it is being used by active queries in this session

ERROR:  cannot CREATE TABLE .. PARTITION OF "..." because it is being used by active queries in this session

このような一次パーティションテーブルを作るときに以下のようなエラーが発生していました。

db1=# CREATE TEMP TABLE t10 (id int, v text)
        PARTITION BY RANGE (id) ON COMMIT DELETE ROWS;
ERROR:  could not open file "base/16543/t3_45678": No such file or directory

この障害はテキスト検索、contrib/ltree、contrib/pg_trgm に影響があります。絵文字に対して pg_trgm の関数を実行して以下エラーが出る例が報告されました。

ERROR: invalid multibyte character for locale

以前はより早くに処理されていたのが、9.6.3、9.5.7 のリリースから本修正前まででは、後回しに処理されるようになっていました。

SP-GiST を使った排他制約が一つのコマンドで多数の新たなインデックスエントリを受け付ける場合に、大きなリーク量が生じることが知られています。

これは psql が NOTIFYメッセージ受信を次コマンドまで報告しないケースを修正します。

一部ケースでチェックサムを持つと想定されないファイルについて、問題報告されることがありました。

pg_read_all_stats は全ての統計情報が参照できるという意味であるため、データを変更できることは不適切でした。変更の反映には導入先の各データベースで以下コマンド実行が必要です。

ALTER EXTENSION pg_stat_statements UPDATE;

Ruby の関数との名前衝突を回避します。PL/Ruby を導入する場合に問題がありました。

PL/Perl と PL/Tcl のビルドに失敗していました。対応として、configureスクリプトが CPPFLAGS に -isysroot を加えるようになりました。そのほか、macOS むけにビルドスクリプトがいくつか修正されました。

Perlは最早カレントディレクトリをデフォルトではサーチパスに含めず、本修正はこれに対応したものです。

Administratorアカウントから駆動したとしても安全であるように、実行プロセスは制約された権限で動作するようになっています。

チリ、フィジー、モロッコ、ロシア（ヴォルゴグラード）の夏時間法の変更と、中国、ハワイ、日本、マカオ、北朝鮮の歴史的修正が含まれています。

これら関数はオブジェクトの不正な OID与えられたときエラーではなく NULLを返すことが期待されていますが、一部においてそうなっていませんでした。さらに、has_column_privilege() 関数は一部プラットフォームでクラッシュする可能性がありました。

この障害によりパースエラーや不正な優先順位が生じる可能性がありました。演算子の後に数値の + や -、あるいはコメント開始記号の -- や /* が続いている場合に誤認されるケースがありました。

（報告された障害動作例）
db=# CREATE FUNCTION f26(a int) RETURNS int LANGUAGE sql
        AS $$ SELECT a; $$;
db=# SELECT f26(a => -1);
 f
----
 -1
(1 row)

db1=# select f(a =>-1);
ERROR:  column "a" does not exist

カーソルを使って FETCH BACKWARD で結果を取得する場合に誤った SELECT結果が返る動作が報告されていました。実行プランとして逆向きスキャンが選ばれる場合にも問題が起きる可能性があります。

複数のリレーション（特に親テーブルを継承した複数のテーブルなど）をスキャンするカーソルは、手前のリレーションに巻き戻された場合に誤動作を起こす可能性がありました。

同時更新をしたときに、なかなか再現しないクラッシュや誤った問い合わせ結果が生じていました。CASE や COALESCE の中にある無関係な副SELECT を含む更新SQL（例えば以下のような形状）で該当します。

WITH d(val) AS (SELECT 'Val'::text FROM generate_series(1,1))
  UPDATE t30 SET v = COALESCE(v, (SELECT val FROM d)) WHERE id = 1;

このような場合、行順序の変化により不確定な結果となって、ワーカごとに異なる応答を得ることから、整合性に欠けた振る舞いが生じることがありました。

所有者変更はこのようなシーケンスにも伝播すべきでしたが、外部テーブルについて見逃されていました。

特に多次元配列のときに確保サイズが大きくなっていました。

これまでファイル記述子のリークがあり、結果としてロジカルデコーディングでのエラーをひき起こしていました。

（エラー例）
ERROR:  53000: exceeded maxAllocatedDescs (492) while trying to open file "pg_logical/mappings/map-4000-4eb-1_60DE1E08-5376b5-537c6b"
LOCATION:  OpenTransientFile, fd.c:2161

VACUUM FULL や CLUSTER コマンドで以下のようなエラーが生じる可能性がありました。

ERROR, "could not map filenode "base/16543/19876" to relation OID"

これまでスタンバイで以下のエラーが出ることがありました。

FATAL:  out-of-order XID insertion in KnownAssignedXids

本障害について、イベントトリガが働く状態で入れ子のパーティションテーブルを作成するときのクラッシュが報告されました。

これにより、transaction_timestamp() などの関数がワーカ上で実行されたときの誤動作が防止されます。

配列型の値などが該当します。SQL実行時に Bus error によるクラッシュが発生していました。

archive_mode の設定によってはスタンバイで一部の本来削除可能なWALファイルの削除に失敗することがありました。

コミットタイムスタンプ追跡が有効または無効に変更されると、それを記録していないトランザクションに対してコミットタイムスタンプを取得しようとしてリカバリに失敗することがありました。

（本障害でリカバリ起動に失敗した報告例）
FATAL: could not access status of transaction 3003911820
DETAIL: Could not read from file "pg_commit_ts/6FEE" at offset 557056: Success.

この変更により、常に同じランダムシードを使うことで生じる名前衝突によって、initdb が POSIX共有メモリが無効であると誤って判断するのを回避できます。

主として問い合わせの並列処理で問題が不具合が発生します。

SQLのパラレル処理とキャンセルで無限ループが生じる可能性がありました。

本障害により以下のエラーが発生するケースが報告されました。

ERROR:  invalid cache ID: 11
LOG: worker process: parallel worker for PID 12345 (PID 12354) exited with exit code 1

off から on に変えた後もフルページ書き出しが行われない動作が報告されました。

バックエンドのアドレス空間にロードされた共有ライブラリは、関数のリンク先に意図しているそれらが持つコピーではなく、バックエンドにあるバージョンを使う可能性がありました。両関数実装が一致していない場合、この振る舞いのために障害がひき起こされます。

クラッシュが発生する例が報告されています。

本障害によりデータ破壊の可能性があります。

該当する場合、本障害によりデータ破壊をひき起こす可能性があります。

サーバ側（WAL送出側）の遅延をタイムアウト判定に含めないように調整されました。

この修正は、スタンバイサーバが WALリプレイでデータベース整合状態に達した直後の誤動作を防止します。

スタンバイサーバのクラッシュ後の起動で、以下メッセージが出て失敗する動作が報告されました。

PANIC:  WAL contains references to invalid pages
DETAIL:  xlog redo at AB3/50323E78 for Btree/DELETE: 182 items

これまで FSM（空き領域マップ）は重要なデータではないと考えられていましたが、FSM が古くなりすぎるとサーバがスタンバイからプライマリに昇格した後、パフォーマンスが大幅に低下する可能性がありました。

呼び出し側が後で逆向きスキャンを求める場合を考慮する必要がありました。

シグナルを受けてハングアップする可能性がありました。

拡張のスクリプトで CREATE USER MAPPING を実行すると、ユーザのマッピングに対して予期せぬ拡張依存関係が作成されました。ロールは拡張の要素にすることはできないため、ユーザマッピングも含めるべきではありませんでした。

これまではファイルを開けなかった場合にそれを報告しようとして無限再帰ループに陥る可能性がありました。

これにより、リスト内の手前にあるサーバに正常に接続できる場合の不要な障害や接続遅延を防止します。

以前は、次の対象ホストに切り替える際にタイマーがリセットされないことがあり、設定よりも早くタイムアウトとなる可能性がありました。

pg_dump で本オプションが機能していませんでした。

これにより制限された検索パスでリストアを実行する場合の障害を回避します。

以前の pg_upgrade はイベントトリガが拡張に属することを維持できせんでした。

以前は、一部の cube 関連関数が cube_in（cube型の入力関数）で拒否される値を生成する可能性があり、ダンプ/リストアの失敗をひき起こしました。

use_remote_estimate = on の場合に「ORDER BY 0」がリモートで実行されて、「ERROR: ORDER BY position 0 is not in select list」が生じるケースがありました。

これまでは search_path を使用して辞書を探していましたが、search_path が制限的な設定であるとき失敗する可能性がありました。

これまでは、データ型固有の比較関数が INT_MIN を返すことを禁止していました。これにより関数の呼び出し元は、比較結果を否定するだけでソート順を逆転させることができました。しかし、POSIX はそのような制限を設けていないので、memcmp() や strcmp() などの結果を直接返す比較関数では、これは安全ではありませんでした。少なくとも最新のバージョンの memcmp() は INT_MIN を返すことがあり、誤った並べ替え順序が発生します。

この制限は削除されました。ソート順を逆にする場合は、INVERT_COMPARE_RESULT() マクロを使用する必要があります。

この障害で VACUUM FULL によって処理されたばかりのシステムカタログやインデックスへのアクセスに失敗することがあります。以下のエラーが報告されました。FATALが生じることもあります。

ERROR:  could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes

本修正で、待機イベントである LockAcquire に対する新しい結果コードが追加されました。このイベントの外部呼出し元に影響を与える可能性があります。しかし、これは非常に珍しい使われ方でのみ発生する問題です。

これにより、1つの SPI を使用する関数が、別の関数を呼び出すときに起こり得る干渉を防ぎます。

新しく UNION型の PGAlignedBlock、PGAlignedXLogBlock を設けて、これらを 単なる char配列の代わりに使用して、コンパイラがアラインメントを外れた開始アドレスにバッファを置くことがないようになりました。これにより一部プラットフォームでのクラッシュを回避します。問題がなかったプラットフォームでもパフォーマンス向上が期待できます。

これまでは C99 以前の振る舞いをしていました。主にWindowsなど、このコードが使われているプラットフォームでは、呼び出しコードが C99 のセマンティクスを前提としていた場合にバッファオーバーランを検出できない可能性がありました。

configure スクリプトの修正です。これにより浮動小数点のオーバーフローチェックが失敗することを回避できます。

以前のリリースでは、Linux 上で icc を使ってビルドする際、間違った結果となりました（恐らく他の組み合わせでも）。これにより、システムから報告されたエラーに対して libpq が有用なエラーメッセージを返さない動作が生じました。

これらのマクロは 9.6 以降は存在していましたが、古いバージョンにも追加して、固有のコーディングなしで拡張機能を利用したいという要望がありました。

ある種の攻撃方法で dblink や postgres_fdw の権限の無いユーザが、サーバを実行する OSユーザが所有する ~/.pgpass などのサーバ側の認証情報ファイルの使用を防止する検査を迂回できました。ローカル接続に peer認証を許可しているサーバは特に影響を受けます。postgres_fdw セッションへの SQLインジェクションなどの他の攻撃も可能です。

この方法で postgres_fdw を攻撃するには指定の接続パラメータで外部サーバオブジェクトが作成できる必要があります。一方、dblink に対しては、dblink にアクセスできる任意のユーザで攻撃可能です。一般に libpq を使ったアプリケーションに対して接続パラメータを選べると攻撃可能になると考えられます。(CVE-2018-10915)

ビューの SELECTリストが元のテーブルの列と1対1で対応していない場合に、更新可能ビューの誤った展開がクラッシュや「ERROR: attribute ... has the wrong type」エラーをもたらす可能性がありました。

さらにセキュリティ上の問題もありました。攻撃者が同テーブルの他の列にINSERTとUPDATE権限を持っている場合に、この障害を利用してUPDATE権限の無い列を更新できました。また、あらゆるユーザがこの障害を使ってサーバメモリの読み取りが可能でした。(CVE-2018-10925)

障害動作例:
（以下のようなテーブル、ビューで）
db1=# CREATE TABLE t2 (id int primary key, c1 int, c2 int);
db1=# CREATE VIEW v2 AS SELECT id, c2 FROM t2;
db1=# GRANT UPDATE (id, c2) ON t2 TO foo;
db1=# GRANT INSERT (id, c2) ON t2 TO foo;
db1=# GRANT ALL ON v2 TO foo;
db1=# INSERT INTO t2 VALUES (1,1,1), (2,2,2);

（一般ユーザ foo で INSERT ... ON CONFLICT ... を実行）
db1=> INSERT INTO v2 (id, c2) VALUES (1,100)
        ON CONFLICT (id) DO UPDATE SET c2 = EXCLUDED.c2;
INSERT 0 1

（奇妙な結果: c2 が更新されず、権限が無い c1 が NULL に更新）
db1=# SELECT * FROM t2;
 id | c1 | c2
----+----+----
  2 |  2 |  2
  1 |    |  1
(3 rows)

過剰に楽観的なキャッシュ処理方式は、これらの更新が他のセッションから見えなくなるおそれがあり、偽性エラー、あるいは/および、データ破損をもたらす可能性がありました。古いキャッシュデータが既存セッションのみならず新たなセッションにまで残り続ける可能性があるため、この問題は pg_authid などの共有カタログにおいて特に悪質です。

以下のエラーが報告されて問題が発見されました。

ERROR:  found xmin 2906288382 from before relfrozenxid 740087784

これは、テーブルに凍結したXID値（relfrozenxid）よりも手前のxmin値を持つレコードが見つかったという意味です。キャッシュ処理の誤りで実際の relfrozenxid値よりもずっと古い値が参照されていました。
同様に「ERROR: found multixact ... from before relminmxid ...」も起こる可能性があります。

本障害により、そのクラッシュ後のリカバリ起動でWALを適用する際に一貫性をもったデータベース状態に到達していないと判断され、起動に失敗しました。

クラッシュ後の起動失敗のときに「PANIC: WAL contains references to invalid pages」が出る動作が報告されています。

この誤りはアサート失敗として現れます。また、潜在的にホットスタンバイサーバで不必要な問い合わせキャンセルを起こすおそれがありました。

このような場合には破損したデータとして扱えるようになりました。これまでは、WALレコード内に書かれたレコード長の通りに大きいメモリ領域を確保しようと試みていました。その結果、以下のような強いエラーが生じてリカバリ不能になっていました。

FATAL:  invalid memory alloc request size ...

本修正でWALの再読み込みを促す弱いエラーを出すように変更されました。

これにより、リカバリクリーンアップ中のエラー（二相コミットの状態ファイルの問題など）でディスク上に一貫性の無いタイムライン状態が生じるのを回避します。

以下のようにリカバリ完了時にrecovery.confが無いというエラーが出て、失敗する動作が報告されていました。

LOG: selected new timeline ID: 2
FATAL: could not open file "recovery.conf": No such file or directory
LOG: startup process (PID 23456) exited with exit code 1

この変更はファイル削除を一括して行うことで、共有バッファがスキャンされる回数を減らして、特に shared_buffers 設定が大きい場合に処理を効率化します。

これまでは上流サーバに追いついているかどうかを誤判定していました。上流側（sender側）の起動時に、既に追いついているのに "streaming" でなく"catchup" 状態と報告することがありました。

この遺漏により、SQL言語の関数を使った制約を持つドメイン型などの一部の場合でクラッシュを起こしていました。

稀な場合において誤ったデコーディング結果を許容していました。ロジカルレプリケーション対象テーブルへのDDL操作や、サブトランザクション(SAVEPOINT)操作があるときに誤動作を起こすおそれがありました。

これまで、いくつかのサブトランザクションが同期テーブルを更新した後に中止(ABORT)された場合に、テーブル同期が誤った振る舞いをする可能性がありました。

これまでは、作成に失敗したインデックスの OID がリストに残り、同セッション内でその後に問題をひき起こしました。

インデックス作成失敗後に当該テーブルに対するSQL実行で「ERROR: could not open relation with OID 16567」エラーが出るケースが報告されました。

これは 9.4 より前の GINインデックスを pg_upgrade した後にアサート失敗をもたらします。9.4 以降のバージョンで GINインデックスを作った場合には問題ありません。

これは多CPUシステムでの競合を減らし、Linux と FreeBSD での旧リリースと比較しての性能退行を修正します。

これまで、パラレルワーカはインデックスページのロックを待機して止まったままとなる可能性がありました。

破損したBtreeインデックスがここでの無限ループをもたらす可能性があり、その場合、これまでは強制クラッシュさせる以外には割り込み不能となっていました。

本障害により、この最適化が適用できる場合に悪いプランが選択される可能性がありました。

inner_unique最適化とは、PostgreSQL 10 で導入されたユニーク保証を使った最適化の一つで、内部結合に適用されます。

本障害のために、複合列のインデックスがマージ結合に対してそれら列のソート順序を提供するかもしれないことが、見落とされていました。

以下のように複合列のインデックスが使われない動作が報告されました。

（このようなテーブルに対して）
db1=# CREATE TYPE typ20c AS (c1 int, c2 int);
db1=# CREATE TABLE tbl20a (c3 typ20c PRIMARY KEY);
db1=# CREATE TABLE tbl20b (c3 typ20c PRIMARY KEY);
db1=# INSERT INTO tbl20a SELECT ROW(g, g)::typ20c
        FROM generate_series(1, 100000) as g;
db1=# INSERT INTO tbl20b SELECT ROW(g, g)::typ20c
        FROM generate_series(1, 100000) as g;
db1=# ANALYZE;

（以下の問い合わせで Merge Join の場合にインデックスが使われない）
db1=# explain SELECT * FROM tbl20a a, tbl20b b WHERE a.c3 = b.c3;

配列型のパーティションキーを使った場合に、検索におけるパーティション除外（pruning）が働かない動作が報告されていました。

これまではプリペアドステートメントでパラメータとすることができませんでした。

（修正前の動作例、LIMIT/OFFSETでは可能だが FETCH FIRSTはエラーになる）
db1=# PREPARE p1 (int, int) AS
        SELECT * FROM t23 LIMIT $2 OFFSET $1;
PREPARE
db1=# PREPARE p2 (int, int) AS
        SELECT * FROM t23 OFFSET $1 ROWS FETCH FIRST $2 ROWS ONLY;
ERROR:  syntax error at or near "$2"

これまで「PARTITION BY RANGE (x, x)」のように同じ列を複数指定すると「ERROR: column "x" appears more than once in partition key」エラーが生じていました。

これまでは許されていましたが、そのような場合は信頼できる動作をしません。

クエリがパラレル動作をするときに EXPLAIN (ANALYZE,BUFFERS) で出力される「Buffers: ...」値が不正確になる動作が報告されました。

照合順序、符号化方式変換、テキスト検索のオブジェクト名が、スキーマ修飾されるべきケースで修飾されませんでした。

PostgreSQL 10.x 系列においては、パブリケーション、拡張統計のオブジェクトも該当します。また、内部実装関数 getObjectIdentity も修正されています。

これにより、COPYの入力が4G（約42.9億、2の32乗）行を超える場合の二つの問題を回避します。一つは COPY FROM WITH HEADER で先頭行のみならず4G行毎に行が捨てられてしまうことで、一つはエラー報告が誤った行番号を報告する可能性があることです。

シングルユーザモードで「SELECT pg_drop_replication_slot('p');」を実行したときに「ERROR: epoll_ctl() failed: Bad file descriptor」となる動作が報告されました。10.0 で埋め込まれてしまった障害です。

varianceは入力値に対する標本分散を返す集約関数です。

稀な状況で本障害により「LOG: could not generate random cancel key」が繰り返し発生して、新たな接続が受け付けられない状態になり、PostgreSQLをサービス再起動する以外では解消できませんでした。

PQhost() が一部の場合に誤解を招く結果または誤った結果を返していました。これからは一定の様式で応答します。ホスト名が指定されていたならホスト名を、ホストアドレスだけ指定されていた場合に限ってホストアドレスを、いずれも指定されていない場合にはデフォルトホスト名（典型的には /tmp かlocalhost）を返すようになりました。

また、SSL証明書を検証するときに誤った値が証明書のサーバ名と比較されるかもしれませんでした。同様に、誤った値が ~/.pgpass のホスト名欄と比較されるかもしれませんでした。これからは、ホスト名が指定されていたならホスト名、ホストアドレスだけ指定されていたならホストアドレス、いずれも指定されていないなら「localhost」が比較対象の値となります。

また、hostaddr値がパース不能であるとき以下のような不適切な（"(null)"部分）エラーメッセージが報告されていたものが修正されました。

$ psql "hostaddr=999.999.999.999"
psql: could not parse network address "(null)": Name or service not known

また、host、hostaddr、portパラメータにカンマ区切りのリストが含まれる場合、libpq はデフォルト動作指定を意味するリスト内の空要素を注意深く扱うようになりました。

Windows で同じ DLLにて malloc して確保したのではないメモリを free すると、クラッシュが発生することがあります。pgtypesライブラリはときどき呼び出し側が解放する想定の文字列を返しますが、そのように使用することは不可能となっていました。PGTYPESchar_free() 関数が追加され、アプリケーションによる呼び出し側でのメモリ解放が可能となりました。

Windows上の ecpg を使用した DBクライアント実行でクライアント側エラー「unsupported type "long long" on line ...」が出るケースが報告されました。

この障害はアサート失敗をひき起こします。また、稀な場合に INTO STRICTオプションが期待通りに動作しなくなります。

以前の pg_dump出力での search_path や他のリスト値変数のクォーティングに対する修正は、空文字列リスト要素に対して誤動作をしていて、長いファイルパスが切り捨てられる危険性がありました。

手動で作成したユニークインデックスは適切に属性が付与されますが、UNIQUE や PRIMARY KEY 制約を宣言して作られる場合にはそうなりませんでした。

これまでは immediateモードのシャットダウンを誤って正常シャットダウンと判断していました。

以下のように hstore型にならない値を渡すときにクラッシュしていました。

db1=# CREATE EXTENSION hstore;
db1=# CREATE EXTENSION plperl;
db1=# CREATE EXTENSION hstore_plperl;
db1=# CREATE FUNCTION test43() RETURNS hstore LANGUAGE plperl
        TRANSFORM FOR TYPE hstore AS $$ return 43; $$;
db1=# SELECT test43();
server closed the connection unexpectedly

ライブラリ関数で使われる errno変数の退避やリセットが不十分な箇所が修正されました。ユーザに対しては、エラーメッセージ中のエラー理由を示す部分に誤ったメッセージが出力されるという形で問題があらわれます。

これにより、古いPostgreSQLライブラリのあるプラットフォームでビルドするときの問題を回避します。

この更新には、過去のナミビアとチェコスロバキアと同様の、アイルランド夏時間の再定義が含まれます。これらの管区では、法律上標準時間が夏で、冬に変更された時間帯が適用されるため、それにあわせた変更が適用されました。実際のUTCオフセットや使われているタイムゾーン略記法に変更はありませんが、pg_timezone_namesビューのis_dst列の値が変わり、冬にtrue、夏にfalseとなります。