Horton

Re: First draft of PG 17 release notes

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-05-15T02:20:11Z
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. Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands

  2. When creating materialized views, use REFRESH to load data.

  3. Revert temporal primary keys and foreign keys

  4. Avoid needless large memcpys in libpq socket writing

  5. Enhance nbtree ScalarArrayOp execution.

  6. Introduce a non-recursive JSON parser

  7. Combine freezing and pruning steps in VACUUM

  8. Allow SIGINT to cancel psql database reconnections.

  9. Provide API for streaming relation data.

  10. Add hash support functions and hash opclass for contrib/ltree.

  11. Pull up ANY-SUBLINK with the necessary lateral support.

  12. Read WAL directly from WAL buffers.

  13. Introduce the dynamic shared memory registry.

  14. Add macros for looping through a List without a ListCell.

  15. Support +/- infinity in the interval data type.

  16. Extend ALTER OPERATOR to allow setting more optimization attributes.

  17. Consider cheap startup paths in add_paths_to_append_rel

Attachments

On Wed, May 15, 2024 at 10:10:28AM +0900, Masahiko Sawada wrote:
> > I looked at that item and I don't have a generic "make logical
> > replication apply faster" item to merge it into, and many
> > subtransactions seemed like enough of an edge-case that I didn't think
> > mentioning it make sense.  Can you see a good place to add it?
> 
> I think that since many subtransactions cases are no longer becoming
> edge-cases these days, we needed to improve that and it might be
> helpful for users to mention it. How about the following item for
> example?
> 
> Improve logical decoding performance in cases where there are many
> subtransactions.

Okay, item added in the attached applied patch.

> > > Finally, should we mention the following commit in the release note?
> > > It's not a user-visible change but added a new regression test module.
> > >
> > > - Add tests for XID wraparound (e255b646a)
> >
> > I don't normally add testing infrastructure changes unless they are
> > major.
> 
> I've seen we had such item, for example in PG14 release note:
> 
> Add a test module for the regular expression package (Tom Lane)
> 
> But if our policy has already changed, I'm okay with not mentioning
> the xid_wraparound test in the PG17 release note.

Uh, that PG 14 test suite was huge and flushed out a lot of bugs, not
only in our regex code but I think in the TCL/Henry Spencer regex
library we inherited.

We add 10-40 tests every year, and how many do I mention in the release
notes?  You had to go back to PG 14 to find one.  We have not changed
our release note "test item" criteria --- I only mention tests that are
significant to our userbase.  I think that test suite was significant to
anyone using the TCL/Henry Spencer regex library.

If you want your test mentioned, you have to explain why it is useful
for users to know about it, or the value it brings them.

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

  Only you can decide what is important to you.