Horton

Re: First draft of PG 17 release notes

Yugo Nagata <nagata@sraoss.co.jp>

View thread
From: Yugo Nagata <nagata@sraoss.co.jp>
To: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-07-26T04:22:24Z
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

Hi,

On Thu, 9 May 2024 00:03:50 -0400
Bruce Momjian <bruce@momjian.us> wrote:

> I have committed the first draft of the PG 17 release notes;  you can
> see the results here:
> 
> 	https://momjian.us/pgsql_docs/release-17.html
> 
> It will be improved until the final release.  The item count is 188,
> which is similar to recent releases:
> 
> 	release-10:  189
> 	release-11:  170
> 	release-12:  180
> 	release-13:  178
> 	release-14:  220
> 	release-15:  184
> 	release-16:  206
> 	release-17:  188
> 
> I welcome feedback.  For some reason it was an easier job than usual.

I found the following in the release notes:

 Change file boundary handling of two WAL file name functions 
 (Kyotaro Horiguchi, Andres Freund, Bruce Momjian)

 The functions pg_walfile_name() and pg_walfile_name_offset() used to report the previous 
 LSN segment number when  the LSN was on a file segment boundary; it now returns the LSN segment. 

It might be trivial, but, reading the associated commit message , I think it would be more explicit
for users to rewrite the last statement to

"it now returns the current LSN segment."

Regards,
Yugo Nagata



> 
> -- 
>   Bruce Momjian  <bruce@momjian.us>        https://momjian.us
>   EDB                                      https://enterprisedb.com
> 
>   Only you can decide what is important to you.
> 
> 


-- 
Yugo Nagata <nagata@sraoss.co.jp>