Horton

Re: PG 18 release notes draft committed

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Noah Misch <noah@leadboat.com>
Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Date: 2025-06-04T20:45:18Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. doc PG 18 relnotes: add AFTER trigger user change item

  2. doc PG 18 relnotes: modify async I/O item for other improvements

  3. doc PG 18 relnotes: split apart log_connections item

  4. doc PG 18 relnotes: move ANALYZE item,split ANALYZE/EXPLAIN item

  5. doc PG 18 relnotes: clarify multiplication item

  6. doc PG 18 relnotes: add removal details to MD5 item

  7. doc PG 18 relnotes: fix markup

  8. doc PG 18 relnotes: clarify btree skip-scan item

  9. doc PG 18 relnotes: update to current

  10. doc PG 18 relnotes: adjust CREATE SUBSCRIPTION attribution

  11. doc PG 18 relnotes: clarify btree skip scan item

  12. doc PG 18 relnotes: mv. hash joins and GROUP BY item to General

  13. Add support for runtime arguments in injection points

  14. doc PG 18 relnotes: fix missing parens for crc32c()

  15. PG 18 relnotes: adjust RETURNING new/old item

  16. doc PG 18 relnotes: adjust pg_log_backend_memory_contexts()

  17. doc PG 18 relnotes: add pg_log_backend_memory_contexts() mention

  18. doc PG 18 relnotes: adjust pgbench per-script reporting item

  19. doc PG 18 relnotes: mention GROUP SET fixes

  20. doc PG 18 relnotes: adjust partition planning item

  21. doc PG 18 relnotes: small adjustments regarding options

  22. doc PG 18 relnotes: move partition locking item to General Perf

  23. doc PG 18 relnotes: adjust partition items

  24. doc PG 18 relnotes: reword OAuth item

  25. doc PG 18 relnotes: add mention of pg_stat_reset_backend_stats()

  26. doc PG 18 relnotes: adjust hash item

  27. doc PG 18 relnotes: split partition optimizer item into two

  28. doc PG 18 relnotes: adjust COPY and REJECT_LIMIT items

  29. doc PG 18 relnotes: move and clarify constraint items

  30. doc PG 18 relnotes: add commit for cancel key and protocol neg.

  31. doc PG 18 relnotes: fix libpq wording

  32. doc PG 18 relnotes: add GROUP BY column elimination item

  33. doc PG 18 relnotes: move protocol version item to "server"

  34. doc PG 18 relnotes: adjust libpq trace & potocol version items

  35. doc PG 18 relnotes: reword and reorder items

  36. doc: Fix memory context level in pg_log_backend_memory_contexts() example.

  37. Make levels 1-based in pg_log_backend_memory_contexts()

  38. Introduce file_copy_method setting.

  39. libpq: Handle NegotiateProtocolVersion message differently

  40. Add timingsafe_bcmp(), for constant-time memory comparison

  41. Optimization for lower(), upper(), casefold() functions.

  42. Fix ALTER SUBSCRIPTION ... SET PUBLICATION ... command.

  43. Add connection establishment duration logging

  44. Modularize log_connections output

  45. Ensure that AFTER triggers run as the instigating user.

  46. Detect redundant GROUP BY columns using UNIQUE indexes

  47. Move cancel key generation to after forking the backend

On Tue, Jun  3, 2025 at 10:21:23AM -0700, Noah Misch wrote:
> On Thu, May 01, 2025 at 10:44:50PM -0400, Bruce Momjian wrote:
> > I have committd the first draft of the PG 18 release notes.
> 
> When a commit changes the user that runs a function in existing queries, I
> think that almost always needs a release notes entry.  It would follow that
> commit 01463e1 needs an entry.  I recommend text "Run each deferred trigger as
> the role that caused the trigger to fire."

Okay, let's look at the commit:

	commit 01463e1cccd
	Author: Tom Lane <tgl@sss.pgh.pa.us>
	Date:   Thu Jan 23 12:25:45 2025 -0500
	
	    Ensure that AFTER triggers run as the instigating user.
	
	    With deferred triggers, it is possible that the current role changes
	    between the time when the trigger is queued and the time it is
	    executed (for example, the triggering data modification could have
	    been executed in a SECURITY DEFINER function).
	
	    Up to now, deferred trigger functions would run with the current role
	    set to whatever was active at commit time.  That does not matter for
	    foreign-key constraints, whose correctness doesn't depend on the
	    current role.  But for user-written triggers, the current role
	    certainly can matter.
	
	    Hence, fix things so that AFTER triggers are fired under the role
	    that was active when they were queued, matching the behavior of
	    BEFORE triggers which would have actually fired at that time.
	    (If the trigger function is marked SECURITY DEFINER, that of course
	    overrides this, as it always has.)
	
	    This does not create any new security exposure: if you do DML on a
	    table owned by a hostile user, that user has always had various ways
	    to exploit your permissions, such as the aforementioned BEFORE
	    triggers, default expressions, etc.  It might remove some security
	    exposure, because the old behavior could potentially expose some
	    other role besides the one directly modifying the table.
	
	    There was discussion of making a larger change, such as running as
	    the trigger's owner.  However, that would break the common idiom of
	    capturing the value of CURRENT_USER in a trigger for auditing/logging
	    purposes.  This change will make no difference in the typical scenario
	    where the current role doesn't change before commit.
	
	    Arguably this is a bug fix, but it seems too big a semantic change
	    to consider for back-patching.
	
	    Author: Laurenz Albe <laurenz.albe@cybertec.at>
	    Reviewed-by: Joseph Koshakow <koshy44@gmail.com>
	    Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>
	    Discussion: https://postgr.es/m/77ee784cf248e842f74588418f55c2931e47bd78.camel@cybertec.at

There are two questions --- should it be mentioned in the release notes,
and should it be listed in the incompatibility section.

It is called a bug fix, which I think means it is just implementing a
behavior that users already expected.  (Yes, there is a doc addition to
clarify this.)  I thought it was an edge case that didn't warrant
mention in the release notes, and the rare cases would be caught in
application testing.

Now, if we do want to mention it, it should be done in a way that makes
it clear to readers whether they are affected by this change.  We can
try text like:

	Execute non-SECURITY-DEFINER AFTER triggers as the role that was
	active at the time the trigger was fired
	
	Previously such triggers were run as the role that was active at
	commit time.

Seems like this would be in the incompatibility section, if we want to
add it.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.