Horton

Re: PG 18 release notes draft committed

Richard Guo <guofenglinux@gmail.com>

View thread
From: Richard Guo <guofenglinux@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-09T03:05:07Z
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 Fri, May 9, 2025 at 11:47 AM Richard Guo <guofenglinux@gmail.com> wrote:
> On Fri, May 9, 2025 at 12:18 AM Bruce Momjian <bruce@momjian.us> wrote:
> > On Thu, May  8, 2025 at 07:46:11PM +0900, Richard Guo wrote:
> > > On Thu, May 8, 2025 at 5:41 AM Bruce Momjian <bruce@momjian.us> wrote:
> > > > On Wed, May  7, 2025 at 03:03:32PM +0900, Richard Guo wrote:
> > > > > I'm wondering if we should consider mentioning that several
> > > > > long-standing issues related to grouping sets have been fixed starting
> > > > > from PostgreSQL v18.  I understand that we typically don't include bug
> > > > > fixes in the release notes, but these particular issues have been
> > > > > present since grouping sets were first introduced, and currently they
> > > > > still exist in the back branches (yeah, for some reason we do not have
> > > > > back-branch fixes; we only fix them in v18 and going forward).
> > > > >
> > > > > There have been complaints from users about grouping sets giving
> > > > > incorrect results in certain cases, which has made them hesitant to
> > > > > use PostgreSQL for analytical workloads.  Since these issues are fixed
> > > > > in v18, it might be worthwhile to point this out — if only to reassure
> > > > > users that these issues are no longer a concern going forward.
> > > > >
> > > > > (FWIW, the related commits are 247dea89f, f5050f795, and cc5d98525).
> > > >
> > > > Agreed, any fix that commonly used to return wrong results should be
> > > > mentioned.  Applied patch attached.
> > >
> > > I'm not sure whether it's appropriate to put the incorrect-result
> > > fixes under the item "Allow some HAVING clauses on GROUPING SETS to
> > > be pushed to WHERE clauses", since that item is an optimization and
> > > does not fix these incorrect-result issues.
> > >
> > > But I'm also unsure where else they should go.  Would it make sense to
> > > list them as a new item instead?
> >
> > I put it there because that is the only mention of GROUPING SETS.  If we
> > create a separate item, would the text just be "This release fixes
> > some GROUPING SETS queries that used to return incorrect results."  Is
> > there any pattern to the fix?  Seems NULLs or subqueries were involved.
> > Is this an incompatibility?  Could people be relying on the old
> > behavior?
>
> I think there are two patterns here:
>
> * 247dea89f and cc5d98525 fix cases where grouping expressions fail to
> match lower-level target items due to expression preprocessing or
> subquery pull-up.  Subqueries are one example of such expressions.
>
> * f5050f795 fixes cases where some seemingly redundant grouping or
> ordering expressions were incorrectly ignored, without recognizing
> that they could be nulled by grouping sets.
>
> I don't think this constitutes an incompatibility, and it's unlikely
> that anyone is relying on the old behavior, as it was clearly
> incorrect.
>
> (I realize these descriptions are too technical, but I'm not sure how
> to express them in a more user-facing way.)

How about putting them this way:

* 247dea89f and cc5d98525 fix queries in which GROUP BY columns
contain expressions that are complex or originate from subqueries.

* f5050f795 fixes queries in which ORDER BY columns contain
expressions that are used in grouping sets.

Thanks
Richard