3 files changed, 37 insertions, 40 deletions
diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
index c464716e3ce..781a01067f7 100644
--- a/doc/src/sgml/postgres-fdw.sgml
+++ b/doc/src/sgml/postgres-fdw.sgml
@@ -1078,21 +1078,6 @@ postgres=# SELECT postgres_fdw_disconnect_all();
   </para>
 
   <para>
-   The remote transaction is opened in the same read/write mode as the local
-   transaction: if the local transaction is <literal>READ ONLY</literal>,
-   the remote transaction is opened in <literal>READ ONLY</literal> mode,
-   otherwise it is opened in <literal>READ WRITE</literal> mode.
-   (This rule is also applied to remote and local subtransactions.)
-  </para>
-
-  <para>
-   The remote transaction is also opened in the same deferrable mode as the
-   local transaction: if the local transaction is <literal>DEFERRABLE</literal>,
-   the remote transaction is opened in <literal>DEFERRABLE</literal> mode,
-   otherwise it is opened in <literal>NOT DEFERRABLE</literal> mode.
-  </para>
-
-  <para>
    Note that it is currently not supported by
    <filename>postgres_fdw</filename> to prepare the remote transaction for
    two-phase commit.
diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml
index 19e770c65b5..c5e60f88fdf 100644
--- a/doc/src/sgml/release-18.sgml
+++ b/doc/src/sgml/release-18.sgml
@@ -54,6 +54,24 @@
    <itemizedlist>
 
 <!--
+Author: Peter Eisentraut <peter@eisentraut.org>
+2024-10-16 [04bec894a04] initdb: Change default to using data checksums.
+-->
+
+<listitem>
+<para>
+Change initdb default to enable data checksums
+<ulink url="&commit_baseurl;04bec894a04">&sect;</ulink>
+</para>
+
+<para>
+Checksums can be disabled with the new initdb option --no-data-checksums.
+pg_upgrade requires matching cluster checksum settings, so this new
+option can be useful to upgrade non-checksum old clusters.
+</para>
+</listitem>
+
+<!--
 Author: Tom Lane <tgl@sss.pgh.pa.us>
 2025-01-16 [d7674c9fa] Seek zone abbreviations in the IANA data before timezone
 -->
@@ -140,6 +158,22 @@ Previously ALTER TABLE SET [UN]LOGGED did nothing, and the creation of an unlogg
 </listitem>
 
 <!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+2025-01-23 [01463e1cc] Ensure that AFTER triggers run as the instigating user.
+-->
+
+<listitem>
+<para>
+Execute AFTER triggers as the role that was active when trigger events were queued (Laurenz Albe)
+</para>
+
+<para>
+Previously such triggers were run as the role that was active at trigger execution time (e.g., at COMMIT).  This is significant for cases where the role is changed between queue time and
+transaction commit.
+</para>
+</listitem>
+
+<!--
 Author: Fujii Masao <fujii@postgresql.org>
 2024-09-12 [fefa76f70] Remove old RULE privilege completely.
 -->
@@ -194,27 +228,6 @@ These were previously zero-based.
 </para>
 </listitem>
 
-<!--
-Author: Peter Eisentraut <peter@eisentraut.org>
-2024-10-16 [04bec894a04] initdb: Change default to using data checksums.
--->
-
-<listitem>
-<para>
-initdb defaults to enabling data checksums
-<ulink url="&commit_baseurl;04bec894a04">&sect;</ulink>
-</para>
-
-<para>
-The previous default behavior (checksums disabled) can be obtained using the
-new option --no-data-checksums.  Note that pg_upgrade will reject upgrading
-between clusters with different checksum settings, so if the old cluster does
-not have checksums enabled (the previous default), then the new cluster will
-need to be initialized with --no-data-checksums in order to allow pg_upgrade
-to succeed.
-</para>
-</listitem>
-
    </itemizedlist>
 
   </sect2>
diff --git a/doc/src/sgml/trigger.sgml b/doc/src/sgml/trigger.sgml
index e9214dcf1b1..bb1b5faf34e 100644
--- a/doc/src/sgml/trigger.sgml
+++ b/doc/src/sgml/trigger.sgml
@@ -129,10 +129,9 @@
     In all cases, a trigger is executed as part of the same transaction as
     the statement that triggered it, so if either the statement or the
     trigger causes an error, the effects of both will be rolled back.
-    Also, the trigger will always run in the security context of the role
-    that executed the statement that caused the trigger to fire, unless
-    the trigger function is defined as <literal>SECURITY DEFINER</literal>,
-    in which case it will run as the function owner.
+    Also, the trigger will always run as the role that queued the trigger
+    event, unless the trigger function is marked as <literal>SECURITY
+    DEFINER</literal>, in which case it will run as the function owner.
    </para>
 
    <para>