We continue to follow the news in the world of PostgreSQL. The PostgreSQL 16 Release Candidate 1 was rolled out on August 31. If all is well, PostgreSQL 16 will officially release on September 14. What has changed in the upcoming release after the April code freeze? What's getting into PostgreSQL 17 after the first commitfest? Read our latest review to find out! For reference, here are our previous reviews of PostgreSQL 16 commitfests: 2022-07, 2022-09, 2022-11, 2023-01, 2023-03. Since April, there have been some notable changes. Let's start with the losses. The following updates have not made it into the release: Some patches have been updated: psql: \drg — a new command for viewing role membership information
commit: d65ddaca The new command was added to PostgreSQL 16 after the code freeze, which is not done very often. However, this patch is just a psql interface update for the server functionality that has been introduced inPostgreSQL 16. Create a role alice with role administration privileges. Make alice automatically inherit the privileges of any created roles and be able to switch to them using SET ROLE: Use the new command \drg to verify that alice is a member of bob with the following parameters: Note that alice is a member of bob twice. The ADMIN OPTION grant was made on behalf of the bootstrap superuser. This is what lets alice manage bob. It may be important to know who granted what membership to whom, since only the grantor can REVOKE the membership. Create a role charlie and grant it membership in bob. In previous versions, membership was displayed in the "Member of" column in the \du (or \dg) output. Turns out, adding the information about the grantor into that column wasn't that easy, so the new command \drg was created instead, and \du and \dg lost the "Member of" column altogether. More about role membership management from our previous commitfest reviews: The parameter io_direct is renamed to debug_io_direct
commit: 319bae9a PostgreSQL 16 introduced a new debugging parameter io_direct. To avoid people accidentally switching it on without understanding what it does, the parameter was renamed to debug_io_direct. Parameters lc_collate and lc_ctype removed
commit: b0f6c437 Starting with PostgreSQL 15, the ICU library can be used as the default localization provider for the database. If it is, information about the selected provider and locale is stored in the columns pg_database.datlocprovider and pg_database.daticulocale. However, for a number of reasons, libc settings are still needed in every database. Therefore, the pg_database.datcollate and pg_database.datctype columns still have information about the libc locale, even if the ICU provider is selected for the database, and the lc_collate and lc_ctype parameters specifically display the libc settings. Therefore, just checking the lc_ctype or lc_collate value is not enough to correctly determine the database locale. You have to check the values of the datlocprovider and daticulocale columns as well. To avoid errors in determining the database locale, the lc_collate and lc_ctype parameters were removed. To view the locale information, you should use pg_database or the \list command in psql from now on. Documentation: links to previously hidden HTML elements visible in the web interface
commit: e2922702 Some HTML documentation pages contain anchors for sections or terms. For example, each configuration parameter in the "Server Configuration" chapter has its own anchor and can be referenced directly. But how do you find out what the anchor is without looking into the page source code? In PostgreSQL16's web interface, when you hover the mouse pointer over the name of a section or term that has an anchor, a # sign now appears on the right with the corresponding hyperlink. For example, if you hover the mouse over the search_path section name on the Client ConnectionDefaults page, a # sign will appear on the right with a direct link to the parameter:
https://www.postgresql.org/docs/16/runtime-config-client.html#GUC-SEARCH-PATH This is very convenient when you need to share an exact link. Now, let's move to version 17. After the first commitfest, the following patches were added: Index vacuuming progress in pg_stat_progress_vacuum
Incremental sorting for GiST and SP-GiST indexes
Exclusion constraints for partitioned tables
Logical replication: REPLICA IDENTITY FULL and hash indexes
pg_archivecleanup: --clean-backup-history
New parameter huge_pages_status
Removed the parameter db_user_namespace
Wait events for extensions
psql: the ECHO_HIDDEN output is now framed with comment lines Index vacuuming progress inpg_stat_progress_vacuum
commit: 46ebdfe1, f1889729 Two new columns were added to the pg_stat_progress_vacuum view: indexes_total and indexes_processed. The first one shows the total number of indexes to be vacuumed, and the second one shows how many indexes have already been processed. The information is updated during the vacuuming phases associated with the indexes: ‘vacuuming indexes’ and ‘cleaning up indexes’. This is an important improvement in monitoring the vacuuming of large tables with multiple indexes, since using pg_stat_progress_vacuum in such cases was leaving a lot to be desired. After all, thanks to the visibility map, vacuuming of the table itself affects only the pages that were changed since the previous vacuuming, so it is performed quickly enough, provided that those changes are small in number. On the other hand, each index is scanned in full, so the index vacuuming phases take up most of the table vacuuming time, and there was no way to track their progress. Now the progress can be evaluated by the number of processed indexes. There is still no way to monitor the progress on the single index level, however. The process is vastly different for different kinds of indexes, and the same index page may be processed multiple times. Therefore, it is impossible to reliably implement monitoring similar to the one used with tables, i.e. number_of_vacuumed_pages / total_number_of_pages. Incremental sorting for GiST and SP-GiSTindexes
commit: 625d5b3c Incremental sorting was first introduced back in PostgreSQL 13, but so far it has only been used for B-tree indexes. Now it works with GiST and SP-GiST indexes too. In the demodatabase, let's create a GiST index by airport coordinates: Find 10 flights from airports closest to a given point (for example, with the coordinates of 0 and 0), and sorted by departure date: Ignore the output here, the interesting thing is that we now get the Incremental Sort node with the GiST index in the query plan. Exclusion constraints for partitioned tables
commit: 8c852ba9 It is now possible to create exclusion constraints for partitioned tables. Create a table for booking meeting rooms, partitioned by room number: To make it impossible to book the same room twice, add an exclusion constraint. Like the primary key, the constraint must include partitioning key columns, and only with the equality operator: Different rooms from different sections can be booked for the same periods of time: But you can't book the same room for overlapping time ranges: Logical replication: REPLICA IDENTITY FULL and hash indexes
commit: edca3424 The ability to use a non-unique index to identify modified rows on the subscriber first appeared in PostgreSQL 16, but it only worked on B-tree indexes. In PostgreSQL 17, it also works with hash indexes. pg_archivecleanup: --clean-backup-history
commit: dd7c60f1, 4a7556f7, 3f8c98d0 The first commit adds the ability to specify long options, the second commit is a refactoring of the existing code, and only the third one implements the original idea by adding a new option --clean-backup-history. This option is used for deleting old backup history files. Previously, these small files were always retained for debugging purposes. New parameter huge_pages_status
commit: a14354ca The new parameterhuge_pages_status shows the usage status of huge pages: Here, the parameter value suggests that the server could not allocate memory for huge pages at startup. Removed the parameter db_user_namespace
commit :884eee5b The parameter was used to relate user names to databases. 21 years ago, this functionality was announced as a temporary measure, but it seems to have never garnered any popularity. Wait events for extensions
commit:c9af0546 Extension developers get the ability to define their own wait events. Currently, all extensions use the same wait event type: Extension. But if several extensions are installed, pg_stat_activity does not give a clear indication as to which extension has caused a delay. The patch introduces an interface for extensions to create wait events. In the future, the developers plan to update the existing contrib extensions to clarify the names of the wait events. psql: the ECHO_HIDDEN output is now framed with comment lines
commit:19c590f6 Enabling the ECHO_HIDDEN parameter in the command line or as a psql variable makes the SQL queries used in psql commands appear in the output: The lines surrounding the query are now output as comment lines, which is convenient for later use in scripts or for copying and pasting. In previous versions, the lines were framed with * signs instead. The same changes were made to --log-file and --single-step. That's all for now. Looking forward to the release of PostgreSQL 16 and the September commitfest for PostgreSQL 17! Технический писатель