aboutsummaryrefslogtreecommitdiff
path: root/doc/src
Commit message (Collapse)AuthorAge
...
* doc: Meson is not experimental on WindowsPeter Eisentraut2025-01-27
| | | | | | | | | | | | | The installation documentation stated that using Meson is experimental. But since this is the only way to build using Visual Studio on Windows, this would imply that that whole build procedure is experimental, which isn't true. So qualify this statement a bit more. We keep the statement that Meson is experimental on other platforms, since it doesn't have full, confirmed feature parity with the make build system. Author: Aleksander Alekseev <aleksander@timescale.com> Discussion: https://www.postgresql.org/message-id/flat/a3e76618-4cb5-4d54-a71c-da4fb8ba571b@eisentraut.org
* Doc: recommend "psql -X" for restoring pg_dump scripts.Tom Lane2025-01-25
| | | | | | | | | | This practice avoids possible problems caused by non-default psql options, such as disabling AUTOCOMMIT. Author: Shinya Kato <Shinya11.Kato@oss.nttdata.com> Reviewed-by: Robert Treat <rob@xzilla.net> Discussion: https://postgr.es/m/96ff23a5d858ff72ca8e823a014d16fe@oss.nttdata.com Backpatch-through: 13
* Fix PDF doc build.Jeff Davis2025-01-25
| | | | | Reported-by: Tom Lane Discussion: https://postgr.es/m/608525.1737781222@sss.pgh.pa.us
* Add SQL function CASEFOLD().Jeff Davis2025-01-24
| | | | | | | | | | | | | Useful for caseless matching. Similar to LOWER(), but avoids edge-case problems with using LOWER() for caseless matching. For collations that support it, CASEFOLD() handles characters with more than two case variations or multi-character case variations. Some characters may fold to uppercase. The results of case folding are also more stable across Unicode versions than LOWER() or UPPER(). Discussion: https://postgr.es/m/a1886ddfcd8f60cb3e905c93009b646b4cfb74c5.camel%40j-davis.com Reviewed-by: Ian Lawrence Barwick
* pgcrypto: Make it possible to disable built-in cryptoDaniel Gustafsson2025-01-24
| | | | | | | | | | | | | | | | | When using OpenSSL and/or the underlying operating system in FIPS mode no non-FIPS certified crypto implementations should be used. While that is already possible by just not invoking the built-in crypto in pgcrypto, this adds a GUC which prohibit the code from being called. This doesn't change the FIPS status of PostgreSQL but can make it easier for sites which target FIPS compliance to ensure that violations cannot occur. Author: Daniel Gustafsson <daniel@yesql.se> Author: Joe Conway <mail@joeconway.com> Reviewed-by: Joe Conway <mail@joeconway.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Discussion: https://postgr.es/m/16b4a157-9ea1-44d0-b7b3-4c85df5de97b@joeconway.com
* pgcrypto: Add function to check FIPS modeDaniel Gustafsson2025-01-24
| | | | | | | | | | | This adds a SQL callable function for reading and returning the status of FIPS configuration of OpenSSL. If OpenSSL is operating with FIPS enabled it will return true, otherwise false. As this adds a function to the SQL file, bump the extension version to 1.4. Author: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Joe Conway <mail@joeconway.com> Discussion: https://postgr.es/m/8f979145-e206-475a-a31b-73c977a4134c@joeconway.com
* Convert sepgsql tests to TAPPeter Eisentraut2025-01-24
| | | | | | | | | | | | | | Add a TAP test for sepgsql. This automates the previously required manual setup before the test. The actual tests are still run by pg_regress, as before, but now called from within the TAP Perl script. The previous manual test script (test_sepgsql) is left in place, since its purpose is (also) to test whether a running instance was properly initialized for sepgsql. But it has been changed to call pg_regress directly and no longer require make. Reviewed-by: Andreas Karlsson <andreas@proxel.se> Discussion: https://www.postgresql.org/message-id/flat/651a5baf-5c45-4a5a-a202-0c8453a4ebf8@eisentraut.org
* Doc: Fix a typo introduced in 4a0e7314f1.Amit Kapila2025-01-24
| | | | | Author: Erik Rijkers <er@xs4all.nl> Discussion: https://postgr.es/m/6e625c81-968e-42d0-802d-edfaf9cfac11@xs4all.nl
* Doc: Fix column name in pg_publication catalog.Amit Kapila2025-01-24
| | | | | | | | | | Commit e65dbc9927 incorrectly spelled the column name in the pg_publication catalog. In passing make the order of columns in the doc match the actual catalog. Author: Shinoda, Noriyoshi <noriyoshi.shinoda@hpe.com> Reviewed-by: Peter Smith <smithpb2250@gmail.com> Discussion: https://postgr.es/m/DM4PR84MB1734F8F140E4477580761F93EEE02@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
* Ensure that AFTER triggers run as the instigating user.Tom Lane2025-01-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Allow NOT VALID foreign key constraints on partitioned tablesÁlvaro Herrera2025-01-23
| | | | | | | | | | | | | | | | This feature was intentionally omitted when FKs were first implemented for partitioned tables, and had been requested a few times; the usefulness is clear. Validation can happen for each partition individually, which is useful to contain the number of locks held and the duration; or it can be executed for the partitioning hierarchy as a single command, which validates all child constraints that haven't been validated already. This is also useful to implement NOT ENFORCED constraints on top. Author: Amul Sul <sulamul@gmail.com> Discussion: https://postgr.es/m/CAAJ_b96Bp=-ZwihPPtuaNX=SrZ0U6ZsXD3+fgARO0JuKa8v2jQ@mail.gmail.com
* Change publication's publish_generated_columns option type to enum.Amit Kapila2025-01-23
| | | | | | | | | | | | | | | The current boolean publish_generated_columns option only supports a binary choice, which is insufficient for future enhancements where generated columns can be of different types (e.g., stored or virtual). The supported values for the publish_generated_columns option are 'none' and 'stored'. Author: Vignesh C <vignesh21@gmail.com> Reviewed-by: Peter Smith <smithpb2250@gmail.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Discussion: https://postgr.es/m/d718d219-dd47-4a33-bb97-56e8fc4da994@eisentraut.org Discussion: https://postgr.es/m/B80D17B2-2C8E-4C7D-87F2-E5B4BE3C069E@gmail.com
* Support RN (roman-numeral format) in to_number().Tom Lane2025-01-22
| | | | | | | | | | | We've long had roman-numeral output support in to_char(), but lacked the reverse conversion. Here it is. Author: Hunaid Sohail <hunaidpgml@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Tomas Vondra <tomas@vondra.me> Discussion: https://postgr.es/m/CAMWA6ybh4M1VQqpmnu2tfSwO+3gAPeA8YKnMHVADeB=XDEvT_A@mail.gmail.com
* Doc: Update the interaction of tablesync with wal_retrieve_retry_interval.Amit Kapila2025-01-22
| | | | | | | | | | In passing, update the documentation that explains the process of initial data replication to explicitly state that it uses a table synchronization worker. Author: Vignesh C Reviewed-by: Peter Smith, Shlok Kyal, Amit Kapila Discussion: https://postgr.es/m/CALDaNm3RxGcD4cDAV5Q0_A4n06F3+AAMpxiyND9Zn0dB86hFmg@mail.gmail.com
* Doc: simplify the tutorial's window-function examples.Tom Lane2025-01-21
| | | | | | | | | | | | | | | | | | For the purposes of this discussion, row_number() is just as good as rank(), and its behavior is easier to understand and describe. So let's switch the examples to using row_number(). Along the way to checking the results given in the tutorial, I found it helpful to extract the empsalary table we use in the regression tests, which is evidently the same data that was used to make these results. So I shoved that into advanced.source to improve the coverage of that file a little. (There's still several pages of the tutorial that are not included in it, but at least now 3.5 Window Functions is covered.) Suggested-by: "David G. Johnston" <david.g.johnston@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/173737973383.1070.1832752929070067441@wrigleys.postgresql.org
* Support PG_UNICODE_FAST locale in the builtin collation provider.Jeff Davis2025-01-17
| | | | | | | | | | | | | | | | | | | | | | The PG_UNICODE_FAST locale uses code point sort order (fast, memcmp-based) combined with Unicode character semantics. The character semantics are based on Unicode full case mapping. Full case mapping can map a single codepoint to multiple codepoints, such as "ß" uppercasing to "SS". Additionally, it handles context-sensitive mappings like the "final sigma", and it uses titlecase mappings such as "Dž" when titlecasing (rather than plain uppercase mappings). Importantly, the uppercasing of "ß" as "SS" is specifically mentioned by the SQL standard. In Postgres, UCS_BASIC uses plain ASCII semantics for case mapping and pattern matching, so if we changed it to use the PG_UNICODE_FAST locale, it would offer better compliance with the standard. For now, though, do not change the behavior of UCS_BASIC. Discussion: https://postgr.es/m/ddfd67928818f138f51635712529bc5e1d25e4e7.camel@j-davis.com Discussion: https://postgr.es/m/27bb0e52-801d-4f73-a0a4-02cfdd4a9ada@eisentraut.org Reviewed-by: Peter Eisentraut, Daniel Verite
* Add documentation about calling version-1 C functions from C.Tom Lane2025-01-17
| | | | | | | | | This topic wasn't really covered before, so fill in some details. Author: Florents Tselai <florents.tselai@gmail.com> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/90853055-5BBD-493D-91E5-721677C7C59B@gmail.com
* Remove flex version checksPeter Eisentraut2025-01-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the flex version checks from configure and meson. The cutoff versions are all so ancient that this is no longer relevant, and what the actual cutoff should be is a bit fuzzy. This also removes the ancient behavior that configure would also accept a "lex" program if it is actuall flex. This aligns the check with meson in this respect. For future reference, as of this commit, these are relevant flex versions: - The hard required minimum is flex 2.5.34 as of commit b1ef48980dd, but this has not actually been tested. - Prior to this, the minimum enforced by configure/meson was flex 2.5.35, which is the oldest present in the buildfarm right now. - As of commit 6fdd5d95634, the oldest version that will compile without warnings due to flex-generated code is flex 2.5.36. - The oldest version that probably still has some practical relevance is flex 2.5.37, which ships with CentOS/RHEL 7. Discussion: https://www.postgresql.org/message-id/1a204ccd-7ae6-478c-a431-407b5c48ccc6@eisentraut.org
* Seek zone abbreviations in the IANA data before timezone_abbreviations.Tom Lane2025-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a time zone abbreviation used in datetime input is defined in the currently active timezone, use that definition in preference to looking in the timezone_abbreviations list. That allows us to correctly handle abbreviations that have different meanings in different timezones. Also, it eliminates an inconsistency between datetime input and datetime output: the non-ISO datestyles for timestamptz have always printed abbreviations taken from the IANA data, not from timezone_abbreviations. Before this fix, it was possible to demonstrate cases where casting a timestamp to text and back fails or changes the value significantly because of that inconsistency. While this change removes the ability to override the IANA data about an abbreviation known in the current zone, it's not clear that there's any real use-case for doing so. But it is clear that this makes life a lot easier for dealing with abbreviations that have conflicts across different time zones. Also update the pg_timezone_abbrevs view to report abbreviations that are recognized via the IANA data, and *not* report any timezone_abbreviations entries that are thereby overridden. Under the hood, there are now two SRFs, one that pulls the IANA data and one that pulls timezone_abbreviations entries. They're combined by logic in the view. This approach was useful for debugging (since the functions can be called on their own). While I don't intend to document the functions explicitly, they might be useful to call directly. Also improve DecodeTimezoneAbbrev's caching logic so that it can cache zone abbreviations found in the IANA data. Without that, this patch would have caused a noticeable degradation of the runtime of timestamptz_in. Per report from Aleksander Alekseev and additional investigation. Discussion: https://postgr.es/m/CAJ7c6TOATjJqvhnYsui0=CO5XFMF4dvTGH+skzB--jNhqSQu5g@mail.gmail.com
* Add OLD/NEW support to RETURNING in DML queries.Dean Rasheed2025-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows the RETURNING list of INSERT/UPDATE/DELETE/MERGE queries to explicitly return old and new values by using the special aliases "old" and "new", which are automatically added to the query (if not already defined) while parsing its RETURNING list, allowing things like: RETURNING old.colname, new.colname, ... RETURNING old.*, new.* Additionally, a new syntax is supported, allowing the names "old" and "new" to be changed to user-supplied alias names, e.g.: RETURNING WITH (OLD AS o, NEW AS n) o.colname, n.colname, ... This is useful when the names "old" and "new" are already defined, such as inside trigger functions, allowing backwards compatibility to be maintained -- the interpretation of any existing queries that happen to already refer to relations called "old" or "new", or use those as aliases for other relations, is not changed. For an INSERT, old values will generally be NULL, and for a DELETE, new values will generally be NULL, but that may change for an INSERT with an ON CONFLICT ... DO UPDATE clause, or if a query rewrite rule changes the command type. Therefore, we put no restrictions on the use of old and new in any DML queries. Dean Rasheed, reviewed by Jian He and Jeff Davis. Discussion: https://postgr.es/m/CAEZATCWx0J0-v=Qjc6gXzR=KtsdvAE7Ow=D=mu50AgOe+pvisQ@mail.gmail.com
* Doc: Improve the Replica Identity information.Amit Kapila2025-01-16
| | | | | | | | | | | This commit improves the Replica Identity information and clarifies its related restrictions. Reported-by: James Coleman Author: Peter Smith Co-authored-by: Robert Treat Reviewed-by: Laurenz Albe, Amit Kapila Discussion: https://postgr.es/m/CAAaqYe_=7qFSqW7qavvhVy58mmzk1uSQ0RReRiUHyKO5znvr7g@mail.gmail.com
* postgres_fdw: SCRAM authentication pass-throughPeter Eisentraut2025-01-15
| | | | | | | | | | | | | | | This enables SCRAM authentication for postgres_fdw when connecting to a foreign server without having to store a plain-text password on user mapping options. This is done by saving the SCRAM ClientKey and ServeryKey from the client authentication and using those instead of the plain-text password for the server-side SCRAM exchange. The new foreign-server or user-mapping option "use_scram_passthrough" enables this. Co-authored-by: Matheus Alcantara <mths.dev@pm.me> Co-authored-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://www.postgresql.org/message-id/flat/27b29a35-9b96-46a9-bc1a-914140869dac@gmail.com
* Change gist stratnum function to use CompareTypePeter Eisentraut2025-01-15
| | | | | | | | | | | | | This changes commit 7406ab623fe in that the gist strategy number mapping support function is changed to use the CompareType enum as input, instead of the "well-known" RT*StrategyNumber strategy numbers. This is a bit cleaner, since you are not dealing with two sets of strategy numbers. Also, this will enable us to subsume this system into a more general system of using CompareType to define operator semantics across index methods. Discussion: https://www.postgresql.org/message-id/flat/E72EAA49-354D-4C2E-8EB9-255197F55330@enterprisedb.com
* psql: Add option to use expanded mode to all list commands.Dean Rasheed2025-01-14
| | | | | | | | | | | | | | | | This allows "x" to be appended to any psql list-like meta-command, forcing its output to be displayed in expanded mode. This improves readability in cases where the output is very wide. For example, "\dfx+" (or equivalently "\df+x") will produce a list of functions, with additional details, in expanded mode. This works with all \d* meta-commands, plus \l, \z, and \lo_list, with the one exception that the expanded mode option "x" cannot be appended to "\d" by itself, since "\dx" already means something else. Dean Rasheed, reviewed by Greg Sabino Mullane. Discussion: https://postgr.es/m/CAEZATCVXJk3KsmCncf7PAVbxdDAUDm3QzDgGT7mBYySWikuOYw@mail.gmail.com
* Consistently spell "leakproof" without a hyphen.Dean Rasheed2025-01-14
| | | | | | | | | The overwhelming majority of places already did this, but a small handful of places had a hyphen. Yugo Nagata. Discussion: https://postgr.es/m/CAEZATCXnnuORE2BoGwHw2zbtVvsPOLhbfVmEk9GxRzK%2Bx3OW-Q%40mail.gmail.com
* psql: Add leakproof indicator to \df+, \do+, \dAo+, and \dC+ output.Dean Rasheed2025-01-14
| | | | | | | | | | | | This allows users to determine whether particular functions are leakproof, and whether the underlying functions used by operators and casts are leakproof. This is useful to determine whether indexes can be used in queries on security barrier views or tables with row-level security policies. Yugo Nagata, reviewed by Erik Wienhold and Dean Rasheed. Discussion: https://postgr.es/m/20240701220817.483f9b645b95611f8b1f65da%40sranhm.sraoss.co.jp
* Make pg_stat_io count IOs as bytes instead of blocks for some operationsMichael Paquier2025-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently in pg_stat_io view, IOs are counted as blocks of size BLCKSZ. There are two limitations with this design: * The actual number of I/O requests sent to the kernel is lower because I/O requests may be merged before being sent. Additionally, it gives the impression that all I/Os are done in block size, which shadows the benefits of merging I/O requests. * Some patches are under work to extend pg_stat_io for the tracking of operations that may not be linked to the block size. For example, WAL read IOs are done in variable bytes and it is not possible to correctly show these IOs in pg_stat_io view, and we want to keep all this data in a single system view rather than spread it across multiple relations to ease monitoring. WaitReadBuffers() can now be tracked as a single read operation worth N blocks. Same for ExtendBufferedRelShared() and ExtendBufferedRelLocal() for extensions. Three columns are added to pg_stat_io for reads, writes and extensions for the byte calculations. op_bytes, which was always hardcoded to BLCKSZ, is removed. IO backend statistics are updated to reflect these changes. Bump catalog version. Author: Nazir Bilal Yavuz Reviewed-by: Bertrand Drouvot, Melanie Plageman Discussion: https://postgr.es/m/CAN55FZ0oqxBaaHAEsj=xFqkzE3n5P=3RA1V_igXwL-RV7QRzyw@mail.gmail.com
* Add support for NOT ENFORCED in CHECK constraintsPeter Eisentraut2025-01-11
| | | | | | | | | | | | | | | | | | | This adds support for the NOT ENFORCED/ENFORCED flag for constraints, with support for check constraints. The plan is to eventually support this for foreign key constraints, where it is typically more useful. Note that CHECK constraints do not currently support ALTER operations, so changing the enforceability of an existing constraint isn't possible without dropping and recreating it. This could be added later. Author: Amul Sul <amul.sul@enterprisedb.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: jian he <jian.universality@gmail.com> Tested-by: Triveni N <triveni.n@enterprisedb.com> Discussion: https://www.postgresql.org/message-id/flat/CAAJ_b962c5AcYW9KUt_R_ER5qs3fUGbe4az-SP-vuwPS-w-AGA@mail.gmail.com
* Consolidate docs for vacuum-related GUCs in new subsectionMelanie Plageman2025-01-10
| | | | | | | | | | | | | | | | | | | | | | | GUCs related to vacuum's freezing behavior were documented in a subsection of the Client Connection Defaults documentation. These GUCs don't belong there, as they affect the freezing behavior of all vacuums -- including autovacuums. There wasn't a clear alternative location, so this commit makes a new "Server Configuration" docs subsection, "Vacuuming", with a subsection for "Freezing". It also moves the "Automatic Vacuuming" subsection and the docs on GUCs controlling cost-based vacuum delay under the new "Vacuuming" subsection. The other vacuum-related GUCs under the "Resource Consumption" subsection have been left in their current location, as they seem to fit there. The GUCs' documentation was largely lifted and shifted. The only modification made was the addition of a few missing <literal> tags. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/flat/CAAKRu_aQUOaMYrcjNuXeSkJtaX9oRUzKP57bsYbC0gVVWS%2BcbA%40mail.gmail.com
* Use @extschema:name@ notation in contrib transform modules.Tom Lane2025-01-09
| | | | | | | | | | | | | Harden hstore_plperl, hstore_plpython, and ltree_plpython against search-path-based attacks by using @extschema:name@ notation to refer to the underlying hstore or ltree data type. This allows removal of the previous documentation warning suggesting that they must be installed in the same schema as the underlying data type. In passing, also improve a para in extend.sgml to suggest using @extschema:name@ for such purposes. Discussion: https://postgr.es/m/692480.1736021695@sss.pgh.pa.us
* doc: Clarify synchronous_standby_names parameter.Fujii Masao2025-01-09
| | | | | | | | | | The synchronous_standby_names GUC allows specifying num_sync, the number of synchronous standbys transactions must wait for replies from. This value must be an integer greater than zero. This commit updates the documentation to clarify this requirement. Reported-by: Asphator <asphator@gmail.com> Discussion: https://postgr.es/m/18663-b02f75cb919f1b60@postgresql.org
* Add passwordcheck.min_password_length.Nathan Bossart2025-01-07
| | | | | | | | | | This new parameter can be used to change the minimum allowed password length (in bytes). Note that it has no effect if a user supplies a pre-encrypted password. Author: Emanuele Musella, Maurizio Boriani Reviewed-by: Tomas Vondra, Bertrand Drouvot, Japin Li Discussion: https://postgr.es/m/CA%2BugDNyYtHOtWCqVD3YkSVYDWD_1fO8Jm_ahsDGA5dXhbDPwrQ%40mail.gmail.com
* Lower default value of autovacuum_worker_slots in initdb as needed.Nathan Bossart2025-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c758119e5b increased the default number of semaphores required for autovacuum workers from 3 to 16. Unfortunately, some systems have very low default settings for SEMMNS, and this change moved the minimum required for Postgres well beyond that limit (see commit 38da053463 for more details). With this commit, initdb will lower the default value for autovacuum_worker_slots as needed, just like it already does for parameters such as max_connections and shared_buffers. We test for (max_connections / 6) slots, which conveniently has the following properties: * For the initial max_connections default of 100, the default of autovacuum_worker_slots will be 16, which is its initial default value specified in the documentation and in guc_tables.c. * For the lowest possible max_connections default of 25, the default of autovacuum_worker_slots will be 4, which means we only need one additional semaphore for autovacuum workers (as compared to before commit c758119e5b). This leaves some wiggle room for new auxiliary workers, etc. on systems with low SEMMNS, and it ensures that the default number of slots will be greater than or equal to the default value of autovacuum_max_workers (3). Reported-by: Tom Lane Suggested-by: Andres Freund Reviewed-by: Tom Lane Discussion: https://postgr.es/m/1346002.1736198977%40sss.pgh.pa.us
* Allow changing autovacuum_max_workers without restarting.Nathan Bossart2025-01-06
| | | | | | | | | | | | | | | | | | | | | | | This commit introduces a new parameter named autovacuum_worker_slots that controls how many autovacuum worker slots to reserve during server startup. Modifying this new parameter's value does require a server restart, but it should typically be set to the upper bound of what you might realistically need to set autovacuum_max_workers. With that new parameter in place, autovacuum_max_workers can now be changed with a SIGHUP (e.g., pg_ctl reload). If autovacuum_max_workers is set higher than autovacuum_worker_slots, a WARNING is emitted, and the server will only start up to autovacuum_worker_slots workers at a given time. If autovacuum_max_workers is set to a value less than the number of currently-running autovacuum workers, the existing workers will continue running, but no new workers will be started until the number of running autovacuum workers drops below autovacuum_max_workers. Reviewed-by: Sami Imseih, Justin Pryzby, Robert Haas, Andres Freund, Yogesh Sharma Discussion: https://postgr.es/m/20240410212344.GA1824549%40nathanxps13
* doc: Clarify log level for VERBOSE messages in maintenance commands.Fujii Masao2025-01-06
| | | | | | | | | | VERBOSE messages from ANALYZE, CLUSTER, REINDEX, and VACUUM are logged at the INFO level, but this detail was missing from the documentation. This commit updates the docs to mention the log level for these messages. Author: Masahiro Ikeda Reviewed-by: Yugo Nagata Discussion: https://postgr.es/m/b4a4b7916982dccd9607c8efb3ce5116@oss.nttdata.com
* Document strange jsonb sort order for empty top level arraysAndrew Dunstan2025-01-03
| | | | | | | | | | | | | | | | Slightly faulty logic in the original jsonb code (commit d9134d0a355) results in an empty top level array sorting less than a json null. We can't change the sort order now since it would affect btree indexes over jsonb, so document the anomaly. Backpatch to all live branches (13 .. 17) In master, also add a code comment noting the anomaly. Reported-by: Yan Chengpen Reviewed-by: Jian He Discussion: https://postgr.es/m/OSBPR01MB45199DD8DA2D1CECD50518188E272@OSBPR01MB4519.jpnprd01.prod.outlook.com
* Update copyright for 2025Bruce Momjian2025-01-01
| | | | Backpatch-through: 13
* Try to avoid semaphore-related test failures on NetBSD/OpenBSD.Tom Lane2024-12-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These two platforms have a remarkably tight default limit on the number of SysV semaphores in the system: SEMMNS is only 60 out-of-the-box. Unless manual action is taken to raise that, we'll only be able to allocate 3 sets of 16 usable semaphores each, leading to initdb setting max_connections to just 20. That's problematic because the core regression tests expect to be able to launch 20 concurrent sessions, leaving us with no headroom. This seems to be the cause of intermittent buildfarm failures on some machines. While there's no getting around the fact that you'd better raise SEMMNS for production use on these platforms, it does seem desirable for "make check" to pass reliably without that. We can make that happen, at least for awhile longer, with two small changes: * Change sysv_sema.c's SEMAS_PER_SET to 19, so that we can eat up all of the available semas not just most of them. * Change initdb to make the smallest max_connections value it will consider be 25 not 20. As of HEAD this will leave us with four free semaphores (using the default values for other relevant parameters such as max_wal_senders). So we won't need to consider this again until we've invented five more background processes. Maybe by then we can switch both these platforms to some other semaphore API. For the moment, do this only in master; there've not been field complaints that might justify a back-patch. Discussion: https://postgr.es/m/db2773a2-aca0-43d0-99c1-060efcd9954e@gmail.com
* Remove pg_attribute.attcacheoff columnDavid Rowley2024-12-20
| | | | | | | | | The column is no longer needed as the offset is now cached in the CompactAttribute struct per commit 5983a4cff. Author: David Rowley Reviewed-by: Andres Freund, Victor Yegorov Discussion: https://postgr.es/m/CAApHDvrBztXP3yx=NKNmo3xwFAFhEdyPnvrDg3=M0RhDs+4vYw@mail.gmail.com
* Add backend-level statistics to pgstatsMichael Paquier2024-12-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new variable-numbered statistics kind in pgstats, where the object ID key of the stats entries is based on the proc number of the backends. This acts as an upper-bound for the number of stats entries that can exist at once. The entries are created when a backend starts after authentication succeeds, and are removed when the backend exits, making the stats entry exist for as long as their backend is up and running. These are not written to the pgstats file at shutdown (note that write_to_file is disabled, as a safety measure). Currently, these stats include only information about the I/O generated by a backend, using the same layer as pg_stat_io, except that it is now possible to know how much activity is happening in each backend rather than an overall aggregate of all the activity. A function called pg_stat_get_backend_io() is added to access this data depending on the PID of a backend. The existing structure could be expanded in the future to add more information about other statistics related to backends, depending on requirements or ideas. Auxiliary processes are not included in this set of statistics. These are less interesting to have than normal backends as they have dedicated entries in pg_stat_io, and stats kinds of their own. This commit includes also pg_stat_reset_backend_stats(), function able to reset all the stats associated to a single backend. Bump catalog version and PGSTAT_FILE_FORMAT_ID. Author: Bertrand Drouvot Reviewed-by: Álvaro Herrera, Kyotaro Horiguchi, Michael Paquier, Nazir Bilal Yavuz Discussion: https://postgr.es/m/ZtXR+CtkEVVE/LHF@ip-10-97-1-34.eu-west-3.compute.internal
* psql: Add more information about service nameMichael Paquier2024-12-18
| | | | | | | | | | | | | | This commit adds support for the following items in psql, able to show a service name, when available: - Variable SERVICE. - Substitution %s in PROMPT{1,2,3}. This relies on 4b99fed7541e, that has made the service name available in PGconn for libpq. Author: Michael Banck Reviewed-by: Greg Sabino Mullane Discussion: https://postgr.es/m/6723c612.050a0220.1567f4.b94a@mx.google.com
* libpq: Add service name to PGconn and PQservice()Michael Paquier2024-12-18
| | | | | | | | | | | | | | This commit adds one field to PGconn for the database service name (if any), with PQservice() as routine to retrieve it. Like the other routines of this area, NULL is returned as result if the connection is NULL. A follow-up patch will make use of this feature to be able to display the service name in the psql prompt. Author: Michael Banck Reviewed-by: Greg Sabino Mullane Discusion: https://postgr.es/m/6723c612.050a0220.1567f4.b94a@mx.google.com
* Doc: Fix the wrong link on pg_createsubscriber page.Amit Kapila2024-12-17
| | | | | | | | | | | Commit 84db9a0eb1 has added the incorrect link to 'initial data synchronization'. It was a subsection of Row Filter and didn't provide the required information. Author: Peter Smith Reviewed-by: Vignesh C, Pavel Luzanov Backpatch-through: 17, where it was introduced Discussion: https://postgr.es/m/CAHut+PtnA4DB_pcv4TDr4NjUSM1=P2N_cuZx5DX09k7LVmaqUA@mail.gmail.com
* doc: Mention BRIN indexes support parallel buildsTomas Vondra2024-12-16
| | | | | | | | | | | Two places in the documentation suggest B-tree is the only index access method allowing parallel builds. Commit b4375717 added parallel builds for BRIN too, but failed to update the docs. So fix that, and backpatch to 17, where parallel BRIN builds were introduced. Author: Egor Rogov Backpatch-through: 17 Discussion: https://postgr.es/m/114e2d5d-125e-07d8-94aa-5ad175fb7443@postgrespro.ru
* doc: Clarify old WAL files are kept until they are summarized.Fujii Masao2024-12-15
| | | | | | | | | | | | | | | The documentation in wal.sgml explains that old WAL files cannot be removed or recycled until they are archived (when WAL archiving is used) or replicated (when using replication slots). However, it did not mention that, similarly, old WAL files are also kept until they are summarized if WAL summarization is enabled. This commit adds that clarification to the documentation. Back-patch to v17 where WAL summarization was added. Author: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/fd0eb0a5-f43b-4e06-b450-cbca011b6cff@oss.nttdata.com
* Add UUID version 7 generation function.Masahiko Sawada2024-12-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit introduces the uuidv7() SQL function, which generates UUID version 7 as specified in RFC 9652. UUIDv7 combines a Unix timestamp in milliseconds and random bits, offering both uniqueness and sortability. In our implementation, the 12-bit sub-millisecond timestamp fraction is stored immediately after the timestamp, in the space referred to as "rand_a" in the RFC. This ensures additional monotonicity within a millisecond. The rand_a bits also function as a counter. We select a sub-millisecond timestamp so that it monotonically increases for generated UUIDs within the same backend, even when the system clock goes backward or when generating UUIDs at very high frequency. Therefore, the monotonicity of generated UUIDs is ensured within the same backend. This commit also expands the uuid_extract_timestamp() function to support UUID version 7. Additionally, an alias uuidv4() is added for the existing gen_random_uuid() SQL function to maintain consistency. Bump catalog version. Author: Andrey Borodin Reviewed-by: Sergey Prokhorenko, Przemysław Sztoch, Nikolay Samokhvalov Reviewed-by: Peter Eisentraut, Jelte Fennema-Nio, Aleksander Alekseev Reviewed-by: Masahiko Sawada, Lukas Fittl, Michael Paquier, Japin Li Reviewed-by: Marcos Pegoraro, Junwang Zhao, Stepan Neretin Reviewed-by: Daniel Vérité Discussion: https://postgr.es/m/CAAhFRxitJv%3DyoGnXUgeLB_O%2BM7J2BJAmb5jqAT9gZ3bij3uLDA%40mail.gmail.com
* Enable BUFFERS with EXPLAIN ANALYZE by defaultDavid Rowley2024-12-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The topic of turning EXPLAIN's BUFFERS option on with the ANALYZE option has come up a few times over the past few years. In many ways, doing this seems like a good idea as it may be more obvious to users why a given query is running more slowly than they might expect. Also, from my own (David's) personal experience, I've seen users posting to the mailing lists with two identical plans, one slow and one fast asking why their query is sometimes slow. In many cases, this is due to additional reads. Having BUFFERS on by default may help reduce some of these questions, and if not, make it more obvious to the user before they post, or save a round-trip to the mailing list when additional I/O effort is the cause of the slowness. The general consensus is that we want BUFFERS on by default with ANALYZE. However, there were more than zero concerns raised with doing so. The primary reason against is the additional verbosity, making it harder to read large plans. Another concern was that buffer information isn't always useful so may not make sense to have it on by default. It's currently December, so let's commit this to see if anyone comes forward with a strong objection against making this change. We have over half a year remaining in the v18 cycle where we could still easily consider reverting this if someone were to come forward with a convincing enough reason as to why doing this is a bad idea. There were two patches independently submitted to achieve this goal, one by me and the other by Guillaume. This commit is a mix of both of these patches with some additional work done by me to adjust various additional places in the documentation which include EXPLAIN ANALYZE output. Author: Guillaume Lelarge, David Rowley Reviewed-by: Robert Haas, Greg Sabino Mullane, Michael Christofides Discussion: https://postgr.es/m/CANNMO++W7MM8T0KyXN3ZheXXt-uLVM3aEtZd+WNfZ=obxffUiA@mail.gmail.com
* Use in-place updates for pg_restore_relation_stats().Jeff Davis2024-12-10
| | | | | | | | This matches the behavior of vac_update_relstats(), which is important to avoid bloating pg_class. Author: Corey Huinker Discussion: https://postgr.es/m/CADkLM=fc3je+ufv3gsHqjjSSf+t8674RXpuXW62EL55MUEQd-g@mail.gmail.com
* Doc: fix incorrect EXPLAIN ANALYZE output for bloom indexesDavid Rowley2024-12-10
| | | | | | | | | | | | It looks like the example case was once modified to increase the number of rows but the EXPLAIN ANALYZE output wasn't updated to reflect that. Also adjust the text which discusses the index sizes. With the example table size, the bloom index isn't quite 8 times more space efficient than the btree indexes. Discussion: https://postgr.es/m/CAApHDvovx8kQ0=HTt85gFDAwmTJHpCgiSvRmQZ_6u_g-vQYM_w@mail.gmail.com Backpatch-through: 13, all supported versions
* doc: remove LC_COLLATE and LC_CTYPE from SHOW commandPeter Eisentraut2024-12-07
| | | | | | | | The corresponding read-only server settings have been removed since in PG16. See commit b0f6c437160db6. Author: Pierre Giraud <pierre.giraud@dalibo.com> Discussion: https://www.postgresql.org/message-id/flat/a75a2fb0-f4b3-4c0c-be3d-7a62d266d760%40dalibo.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-08 17:44:30 +0000