aboutsummaryrefslogtreecommitdiff
path: root/doc/src
Commit message (Collapse)AuthorAge
...
* doc: Update catalog documentation for attstattarget nullablePeter Eisentraut2024-01-14
| | | | Fixup for 4f622503d6.
* Make attstattarget nullablePeter Eisentraut2024-01-13
| | | | | | | | | | | | | | | | | | | | | | | | This changes the pg_attribute field attstattarget into a nullable field in the variable-length part of the row. If no value is set by the user for attstattarget, it is now null instead of previously -1. This saves space in pg_attribute and tuple descriptors for most practical scenarios. (ATTRIBUTE_FIXED_PART_SIZE is reduced from 108 to 104.) Also, null is the semantically more correct value. The ANALYZE code internally continues to represent the default statistics target by -1, so that that code can avoid having to deal with null values. But that is now contained to the ANALYZE code. Only the DDL code deals with attstattarget possibly null. For system columns, the field is now always null. The ANALYZE code skips system columns anyway. To set a column's statistics target to the default value, the new command form ALTER TABLE ... SET STATISTICS DEFAULT can be used. (SET STATISTICS -1 still works.) Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://www.postgresql.org/message-id/flat/4da8d211-d54d-44b9-9847-f2a9f1184c76@eisentraut.org
* Re-validate connection string in libpqrcv_connect().Jeff Davis2024-01-12
| | | | | | | | | | | | | | | | | | | A superuser may create a subscription with password_required=true, but which uses a connection string without a password. Previously, if the owner of such a subscription was changed to a non-superuser, the non-superuser was able to utilize a password from another source (like a password file or the PGPASSWORD environment variable), which should not have been allowed. This commit adds a step to re-validate the connection string before connecting. Reported-by: Jeff Davis Author: Vignesh C Reviewed-by: Peter Smith, Robert Haas, Amit Kapila Discussion: https://www.postgresql.org/message-id/flat/e5892973ae2a80a1a3e0266806640dae3c428100.camel%40j-davis.com Backpatch-through: 16
* Fix typo.Robert Haas2024-01-12
| | | | | | Noriyoshi Shinoda Discussion: http://postgr.es/m/DM4PR84MB17347D9466419413698105D8EE6F2@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
* Added literal tag for RETURNINGAlvaro Herrera2024-01-12
| | | | | | | | This is an old mistake (92e38182d7c8); backpatch all the way back. Author: Atsushi Torikoshi <torikoshia@oss.nttdata.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Discussion: https://postgr.es/m/c0aa00b60a16c0ea2a4c5123b013acb9@oss.nttdata.com
* Add new pg_walsummary tool.Robert Haas2024-01-11
| | | | | | | | | This can dump the contents of the WAL summary files found in pg_wal/summaries. Normally, this shouldn't really be something anyone needs to do, but it may be needed for debugging problems with incremental backup, or could possibly be useful to external tools. Discussion: http://postgr.es/m/CA+Tgmobvqqj-DW9F7uUzT-cQqs6wcVb-Xhs=w=hzJnXSE-kRGw@mail.gmail.com
* Add new function pg_get_wal_summarizer_state().Robert Haas2024-01-11
| | | | | | | | | | This makes it possible to access information about the progress of WAL summarization from SQL. The previously-added functions pg_available_wal_summaries() and pg_wal_summary_contents() only examine on-disk state, but this function exposes information from the server's shared memory. Discussion: http://postgr.es/m/CA+Tgmobvqqj-DW9F7uUzT-cQqs6wcVb-Xhs=w=hzJnXSE-kRGw@mail.gmail.com
* Fix omission in partitioning limitation documentationMagnus Hagander2024-01-11
| | | | | | | | | | | | UNIQUE and PRIMARY KEY constraints can be created on ONLY the partitioned table. We already had an example demonstrating that, but forgot to mention it in the documentation of the limits of partitioning. Author: Laurenz Albe Reviewed-By: shihao zhong, Shubham Khanna, Ashutosh Bapat Backpatch-through: 12 Discussion: https://postgr.es/m/167299368731.659.16130012959616771853@wrigleys.postgresql.org
* Update documentation of default fdw_tuple_costJohn Naylor2024-01-11
| | | | | | | | | | Follow up to cac169d68 Umair Shahid Reviewed by Richard Guo and Chris Travers Discussion: https://postgr.es/m/CALVUYo9RECc5gwD%2B4SRM5Es%2Bbg9cpNfhd3_qUjf7kVTGyLpFJg%40mail.gmail.com
* doc: clarify who owns the initdb-created cluster, by defaultBruce Momjian2024-01-10
| | | | | | Discussion: https://postgr.es/m/ZZoTBSdKeBG_HZ7A@momjian.us Backpatch-through: 16
* Document WAL summarization information functions.Robert Haas2024-01-09
| | | | | | | Commit 174c480508ac25568561443e6d4a82d5c1103487 added two new information functions but failed to document them anywhere. Discussion: http://postgr.es/m/CA+Tgmobvqqj-DW9F7uUzT-cQqs6wcVb-Xhs=w=hzJnXSE-kRGw@mail.gmail.com
* Fix documentation for wal_summary_keep_time.Nathan Bossart2024-01-09
| | | | | | | | | | The documentation for this parameter lists its type as boolean, but it is actually an integer. Furthermore, there is no mention of how the value is interpreted when specified without units. This commit fixes these oversights in commit 174c480508. Co-authored-by: Hubert Depesz Lubaczewski Discussion: https://postgr.es/m/ZZwkujFihO2uqKwp%40depesz.com
* Add new function, PQchangePassword(), to libpqJoe Conway2024-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | Essentially this moves the non-interactive part of psql's "\password" command into an exported client function. The password is not sent to the server in cleartext because it is "encrypted" (in the case of scram and md5 it is actually hashed, but we have called these encrypted passwords for a long time now) on the client side. This is good because it ensures the cleartext password is never known by the server, and therefore won't end up in logs, pg_stat displays, etc. In other words, it exists for the same reason as PQencryptPasswordConn(), but is more convenient as it both builds and runs the "ALTER USER" command for you. PQchangePassword() uses PQencryptPasswordConn() to do the password encryption. PQencryptPasswordConn() is passed a NULL for the algorithm argument, hence encryption is done according to the server's password_encryption setting. Also modify the psql client to use the new function. That provides a builtin test case. Ultimately drivers built on top of libpq should expose this function and its use should be generally encouraged over doing ALTER USER directly for password changes. Author: Joe Conway Reviewed-by: Tom Lane Discussion: https://postgr.es/m/flat/b75955f7-e8cc-4bbd-817f-ef536bacbe93%40joeconway.com
* Doc: fix character_sets view.Tatsuo Ishii2024-01-09
| | | | | | | | | | | | | | | The note regarding character encoding form in "The Information Schema" said that LATIN1 character repertoires only use one encoding form LATIN1. This is not correct because LATIN1 has another encoding form ISO-2022-JP-2. To fix this, replace LATIN1 with LATIN2, which is not supported by ISO-2022-JP-2, thus it can be said that LATIN2 only uses one encoding form. Back-patch to supported branches. Author: Tatsuo Ishii Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/flat/20240102.153925.1147403616414525145.t-ishii%40sranhm.sra.co.jp
* Make dblink interruptible, via new libpqsrv APIs.Noah Misch2024-01-08
| | | | | | | | | | | | | | | This replaces dblink's blocking libpq calls, allowing cancellation and allowing DROP DATABASE (of a database not involved in the query). Apart from explicit dblink_cancel_query() calls, dblink still doesn't cancel the remote side. The replacement for the blocking calls consists of new, general-purpose query execution wrappers in the libpqsrv facility. Out-of-tree extensions should adopt these. Use them in postgres_fdw, replacing a local implementation from which the libpqsrv implementation derives. This is a bug fix for dblink. Code inspection identified the bug at least thirteen years ago, but user complaints have not appeared. Hence, no back-patch for now. Discussion: https://postgr.es/m/20231122012945.74@rfd.leadboat.com
* In plpgsql, allow %TYPE and %ROWTYPE to be followed by array decoration.Tom Lane2024-01-04
| | | | | | | | | This provides the useful ability to declare a variable that is an array of the type of some other variable or some table column. Quan Zongliang, Pavel Stehule Discussion: https://postgr.es/m/ec4523e1-9e7e-f3ef-f9ce-bafd680ad6f6@yeah.net
* ALTER TABLE command to change generation expressionPeter Eisentraut2024-01-04
| | | | | | | | | | | | | | | | | | | This adds a new ALTER TABLE subcommand ALTER COLUMN ... SET EXPRESSION that changes the generation expression of a generated column. The syntax is not standard but was adapted from other SQL implementations. This command causes a table rewrite, using the usual ALTER TABLE mechanisms. The implementation is similar to and makes use of some of the infrastructure of the SET DATA TYPE subcommand (for example, rebuilding constraints and indexes afterwards). The new command requires a new pass in AlterTablePass, and the ADD COLUMN pass had to be moved earlier so that combinations of ADD COLUMN and SET EXPRESSION can work. Author: Amul Sul <sulamul@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAAJ_b94yyJeGA-5M951_Lr+KfZokOp-2kXicpmEhi5FXhBeTog@mail.gmail.com
* Track conflict_reason in pg_replication_slots.Amit Kapila2024-01-04
| | | | | | | | | | | | | | | | | | | | | This patch changes the existing 'conflicting' field to 'conflict_reason' in pg_replication_slots. This new field indicates the reason for the logical slot's conflict with recovery. It is always NULL for physical slots, as well as for logical slots which are not invalidated. The non-NULL values indicate that the slot is marked as invalidated. Possible values are: wal_removed = required WAL has been removed. rows_removed = required rows have been removed. wal_level_insufficient = the primary doesn't have a wal_level sufficient to perform logical decoding. The existing users of 'conflicting' column can get the same answer by using 'conflict_reason' IS NOT NULL. Author: Shveta Malik Reviewed-by: Amit Kapila, Bertrand Drouvot, Michael Paquier Discussion: https://postgr.es/m/ZYOE8IguqTbp-seF@paquier.xyz
* Update copyright for 2024Bruce Momjian2024-01-03
| | | | | | | | Reported-by: Michael Paquier Discussion: https://postgr.es/m/ZZKTDPxBBMt3C0J9@paquier.xyz Backpatch-through: 12
* doc: fix typo "vertexes" -> "vertices"Michael Paquier2024-01-04
| | | | | | | | | The "vertexes" spelling is also valid, but we consistently use "vertices" elsewhere. Author: Dagfinn Ilmari Mannsåker Reviewed-by: Shubham Khanna Discussion: https://postgr.es/m/87le9fmi01.fsf@wibble.ilmari.org
* Revert "Reorganise jsonpath operators and methods"Peter Eisentraut2024-01-03
| | | | | | | | This reverts commit 283a95da923605c1cc148155db2d865d0801b419. The reordering of JsonPathItemType affects the binary on-disk compatibility of the jsonpath type, so we must not change it. Revert for now and consider.
* Doc: Python's control flow construct is try/except not try/catch.Tom Lane2024-01-03
| | | | | | | Very ancient thinko, dating evidently to 22690719e. Spotted by gweatherby. Discussion: https://postgr.es/m/170423637139.1288848.11840082988774620003@wrigleys.postgresql.org
* Reorganise jsonpath operators and methodsPeter Eisentraut2024-01-03
| | | | | | | | | Various jsonpath operators and methods add various keywords, switch cases, and documentation entries in some order. However, they are not consistent; reorder them for better maintainability or readability. Author: Jeevan Chalke <jeevan.chalke@enterprisedb.com> Discussion: https://www.postgresql.org/message-id/flat/CAM2+6=XjTyqrrqHAOj80r0wVQxJSxc0iyib9bPC55uFO9VKatg@mail.gmail.com
* Allow upgrades to preserve the full subscription's state.Amit Kapila2024-01-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature will allow us to replicate the changes on subscriber nodes after the upgrade. Previously, only the subscription metadata information was preserved. Without the list of relations and their state, it's not possible to re-enable the subscriptions without missing some records as the list of relations can only be refreshed after enabling the subscription (and therefore starting the apply worker). Even if we added a way to refresh the subscription while enabling a publication, we still wouldn't know which relations are new on the publication side, and therefore should be fully synced, and which shouldn't. To preserve the subscription relations, this patch teaches pg_dump to restore the content of pg_subscription_rel from the old cluster by using binary_upgrade_add_sub_rel_state SQL function. This is supported only in binary upgrade mode. The subscription's replication origin is needed to ensure that we don't replicate anything twice. To preserve the replication origins, this patch teaches pg_dump to update the replication origin along with creating a subscription by using binary_upgrade_replorigin_advance SQL function to restore the underlying replication origin remote LSN. This is supported only in binary upgrade mode. pg_upgrade will check that all the subscription relations are in 'i' (init) or in 'r' (ready) state and will error out if that's not the case, logging the reason for the failure. This helps to avoid the risk of any dangling slot or origin after the upgrade. Author: Vignesh C, Julien Rouhaud, Shlok Kyal Reviewed-by: Peter Smith, Masahiko Sawada, Michael Paquier, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/20230217075433.u5mjly4d5cr4hcfe@jrouhaud
* Add GUC backtrace_on_internal_errorPeter Eisentraut2023-12-30
| | | | | | | | | | | | | | | When enabled (default off), this logs a backtrace anytime elog() or an equivalent ereport() for internal errors is called. This is not well covered by the existing backtrace_functions, because there are many equally-worded low-level errors in many functions. And if you find out where the error is, then you need to manually rewrite the elog() to ereport() to attach the errbacktrace(), which is annoying. Having a backtrace automatically on every elog() call could be very helpful during development for various kinds of common errors from palloc, syscache, node support, etc. Discussion: https://www.postgresql.org/message-id/flat/ba76c6bc-f03f-4285-bf16-47759cfcab9e@eisentraut.org
* Make all Perl warnings fatalPeter Eisentraut2023-12-29
| | | | | | | | | | | | | | | | | | | | | | | | There are a lot of Perl scripts in the tree, mostly code generation and TAP tests. Occasionally, these scripts produce warnings. These are probably always mistakes on the developer side (true positives). Typical examples are warnings from genbki.pl or related when you make a mess in the catalog files during development, or warnings from tests when they massage a config file that looks different on different hosts, or mistakes during merges (e.g., duplicate subroutine definitions), or just mistakes that weren't noticed because there is a lot of output in a verbose build. This changes all warnings into fatal errors, by replacing use warnings; by use warnings FATAL => 'all'; in all Perl files. Discussion: https://www.postgresql.org/message-id/flat/06f899fd-1826-05ab-42d6-adeb1fd5e200%40eisentraut.org
* doc: Mention AttributeRelationId in FDW validator function descriptionMichael Paquier2023-12-28
| | | | | | | | | | | The documentation has been missing one value in the list of catalog OIDs that can be given to the validator function of a FDW, as of AttributeRelationId, when changing the attribute options of a foreign table. Author: Ian Lawrence Barwick Discussion: https://postgr.es/m/CAB8KJ=i16t2yJU_Pq2Z+hnNGWFhagp_bJmzxHZu3ZkOjZm-+rQ@mail.gmail.com Backpatch-through: 12
* Doc: specify aclitem syntax more clearly.Tom Lane2023-12-27
| | | | | | | | | | The previous wording here relied solely on an example to explain aclitem output format. Add an actual syntax synopsis and explanation of the elements to make it clearer. David Johnston and Tom Lane, per gripe from Eugen Konkov. Discussion: https://postgr.es/m/170326116972.1876499.18357820037829248593@wrigleys.postgresql.org
* doc: add ISO 8601 extended format example using to_char()Bruce Momjian2023-12-26
| | | | | | | | | | Reported-by: juha.mustonen@iki.fi Discussion: https://postgr.es/m/20170217160154.6101.52806@wrigleys.postgresql.org Co-authored-by: Erik Wienhold Backpatch-through: master
* Doc: Add missing pgoutput options.Amit Kapila2023-12-26
| | | | | | | | | We forgot to update the docs while adding new options in pgoutput. Author: Emre Hasegeli Reviewed-by: Peter Smith, Amit Kapila Backpatch-through: 12 Discussion: https://postgr.es/m/CAE2gYzwdwtUbs-tPSV-QBwgTubiyGD2ZGsSnAVsDfAGGLDrGOA%40mail.gmail.com
* Enhance checkpointer restartpoint statisticsAlexander Korotkov2023-12-25
| | | | | | | | | | | | | | | | | | | | | | | | Bhis commit introduces enhancements to the pg_stat_checkpointer view by adding three new columns: restartpoints_timed, restartpoints_req, and restartpoints_done. These additions aim to improve the visibility and monitoring of restartpoint processes on replicas. Previously, it was challenging to differentiate between successful and failed restartpoint requests. This limitation arises because restartpoints on replicas are dependent on checkpoint records from the primary, and cannot occur more frequently than these checkpoints. The new columns allow for clear distinction and tracking of restartpoint requests, their triggers, and successful completions. This enhancement aids database administrators and developers in better understanding and diagnosing issues related to restartpoint behavior, particularly in scenarios where restartpoint requests may fail. System catalog is changed. Catversion is bumped. Discussion: https://postgr.es/m/99b2ccd1-a77a-962a-0837-191cdf56c2b9%40inbox.ru Author: Anton A. Melnikov Reviewed-by: Kyotaro Horiguchi, Alexander Korotkov
* Stop generating plain-text INSTALL instructions.Tom Lane2023-12-22
| | | | | | | | | | | | | | | | | | | | Up to now, our distribution tarballs have included a plain-text form of the installation.sgml chapter. The rationale for that was that a recipient might not have either ready internet access or HTML-viewing tools; a theory that seems downright quaint today. Maintaining the ability to generate this file is not without cost, because it puts special requirements on installation.sgml that are often overlooked. Moreover, we are moving in the direction of making our distribution tarballs be pure git snapshots for traceability/reproducibility reasons; including generated files doesn't fit into that plan. Hence, let's just drop INSTALL and remove the infrastructure for generating it. The top-level README will now recommend visiting our website to see the installation instructions. As a useful side-effect, we can get rid of README.git which has provoked confusion. Discussion: https://postgr.es/m/20231220114927.faccqqprmuyrzdip@alap3.anarazel.de Discussion: https://postgr.es/m/e07408d9-e5f2-d9fd-5672-f53354e9305e@eisentraut.org
* Fix numerous typos in incremental backup commits.Robert Haas2023-12-21
| | | | | | | | | Apparently, spell check would have been a really good idea. Alexander Lakhin, with a few additions as per an off-list report from Andres Freund. Discussion: http://postgr.es/m/f08f7c60-1ad3-0b57-d580-54b11f07cddf@gmail.com
* doc: Fix typo in pg_combinebackup documentationDaniel Gustafsson2023-12-20
| | | | Commit dc2123400 accidentally misspelled "combination".
* Add support for incremental backup.Robert Haas2023-12-20
| | | | | | | | | | | | | | | | | | | | | | To take an incremental backup, you use the new replication command UPLOAD_MANIFEST to upload the manifest for the prior backup. This prior backup could either be a full backup or another incremental backup. You then use BASE_BACKUP with the INCREMENTAL option to take the backup. pg_basebackup now has an --incremental=PATH_TO_MANIFEST option to trigger this behavior. An incremental backup is like a regular full backup except that some relation files are replaced with files with names like INCREMENTAL.${ORIGINAL_NAME}, and the backup_label file contains additional lines identifying it as an incremental backup. The new pg_combinebackup tool can be used to reconstruct a data directory from a full backup and a series of incremental backups. Patch by me. Reviewed by Matthias van de Meent, Dilip Kumar, Jakub Wartak, Peter Eisentraut, and Álvaro Herrera. Thanks especially to Jakub for incredibly helpful and extensive testing. Discussion: http://postgr.es/m/CA+TgmoYOYZfMCyOXFyC-P+-mdrZqm5pP2N7S-r0z3_402h9rsA@mail.gmail.com
* Add a new WAL summarizer process.Robert Haas2023-12-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When active, this process writes WAL summary files to $PGDATA/pg_wal/summaries. Each summary file contains information for a certain range of LSNs on a certain TLI. For each relation, it stores a "limit block" which is 0 if a relation is created or destroyed within a certain range of WAL records, or otherwise the shortest length to which the relation was truncated during that range of WAL records, or otherwise InvalidBlockNumber. In addition, it stores a list of blocks which have been modified during that range of WAL records, but excluding blocks which were removed by truncation after they were modified and never subsequently modified again. In other words, it tells us which blocks need to copied in case of an incremental backup covering that range of WAL records. But this doesn't yet add the capability to actually perform an incremental backup; the next patch will do that. A new parameter summarize_wal enables or disables this new background process. The background process also automatically deletes summary files that are older than wal_summarize_keep_time, if that parameter has a non-zero value and the summarizer is configured to run. Patch by me, with some design help from Dilip Kumar and Andres Freund. Reviewed by Matthias van de Meent, Dilip Kumar, Jakub Wartak, Peter Eisentraut, and Álvaro Herrera. Discussion: http://postgr.es/m/CA+TgmoYOYZfMCyOXFyC-P+-mdrZqm5pP2N7S-r0z3_402h9rsA@mail.gmail.com
* Fix generation of distribution tarballMichael Paquier2023-12-20
| | | | | | | 1301c80b2167 has introduced in installation.sgml a link reference that `make dist` was not able to understand. Per buildfarm member guaibasaurus.
* Remove MSVC scriptsMichael Paquier2023-12-20
| | | | | | | | | | | | | | | | | This commit removes all the scripts located in src/tools/msvc/ to build PostgreSQL with Visual Studio on Windows, meson becoming the recommended way to achieve that. The scripts held some information that is still relevant with meson, information kept and moved to better locations. Comments that referred directly to the scripts are removed. All the documentation still relevant that was in install-windows.sgml has been moved to installation.sgml under a new subsection for Visual. All the content specific to the scripts is removed. Some adjustments for the documentation are planned in a follow-up set of changes. Author: Michael Paquier Reviewed-by: Peter Eisentraut, Andres Freund Discussion: https://postgr.es/m/ZQzp_VMJcerM1Cs_@paquier.xyz
* doc: Fix syntax in ALTER FOREIGN DATA WRAPPER exampleDaniel Gustafsson2023-12-19
| | | | | | | | | | | | | | | | | | | | | The example for dropping an option was incorrectly quoting the option key thus making it a value turning the command into an unqualified ADD operation. The result of dropping became adding a new key/value pair instead: d=# alter foreign data wrapper f options (drop 'b'); ALTER FOREIGN DATA WRAPPER d=# select fdwoptions from pg_foreign_data_wrapper where fdwname='f'; fdwoptions ------------ {drop=b} (1 row) This has been incorrect for a long time so backpatch to all supported branches. Author: Tim <tim.needham2@gmail.com> Discussion: https://postgr.es/m/170292280173.1876505.5204623074024041738@wrigleys.postgresql.org
* Provide vectored variants of smgrread() and smgrwrite().Thomas Munro2023-12-18
| | | | | | | | | | | | | | | | | | | | | | | | | | smgrreadv() and smgrwritev() and their md.c implementations call FileReadV() and FileWriteV(). A range of disk blocks beginning at 'blocknum' and extending for 'nblocks' can be scattered to or gathered from multiple buffers with a single system call. The traditional smgrread() and smgrwrite() functions are implemented in terms of the new functions. Later commits will introduce calls with nblocks > 1, but the following behavioral changes can be seen already: * After a short transfer we'll now retry until we eventually read 0 bytes (= EOF) or get ENOSPC, EDQUOT, EFBIG etc, where previously we would infer the reason. Retrying is consistent with xlog.c's treatment of large WAL writes, and arguably also xlog.c and fd.c's treatment of EINTR. Arbitrary short returns for larger transfers have been observed on several OSes, and might in theory also happen for transient reasons with our own pg_p*v() fallback code. * After unexpected EOF or -1, the error thrown now talks about a range even for the single block case, eg "blocks 42..42". Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6uT5TUm2gkvA@mail.gmail.com
* Doc: add a bit to indices.sgml about what is an indexable clause.Tom Lane2023-12-17
| | | | | | | | We didn't explain this clearly until somewhere deep in the "Extending SQL" chapter, but really it ought to be mentioned in the introductory material too. Discussion: https://postgr.es/m/4097442.1694967650@sss.pgh.pa.us
* docs: Fix typo in pg_stat_statements documentationDaniel Gustafsson2023-12-13
| | | | Commit dc9f8a79830 accidentally misspelled minimum as minimun.
* Remove trace_recovery_messagesMichael Paquier2023-12-11
| | | | | | | | | | | | This GUC was intended as a debugging help in the 9.0 area when hot standby and streaming replication were being developped, able to offer more information at LOG level rather than DEBUGn. There are more tools available these days that are able to offer rather equivalent information, like pg_waldump introduced in 9.3. It is not obvious how this facility is useful these days, so let's remove it. Author: Bharath Rupireddy Discussion: https://postgr.es/m/ZXEXEAUVFrvpquSd@paquier.xyz
* Allow parallel CREATE INDEX for BRIN indexesTomas Vondra2023-12-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow using multiple worker processes to build BRIN index, which until now was supported only for BTREE indexes. For large tables this often results in significant speedup when the build is CPU-bound. The work is split in a simple way - each worker builds BRIN summaries on a subset of the table, determined by the regular parallel scan used to read the data, and feeds them into a shared tuplesort which sorts them by blkno (start of the range). The leader then reads this sorted stream of ranges, merges duplicates (which may happen if the parallel scan does not align with BRIN pages_per_range), and adds the resulting ranges into the index. The number of duplicate results produced by workers (requiring merging in the leader process) should be fairly small, thanks to how parallel scans assign chunks to workers. The likelihood of duplicate results may increase for higher pages_per_range values, but then there are fewer page ranges in total. In any case, we expect the merging to be much cheaper than summarization, so this should be a win. Most of the parallelism infrastructure is a simplified copy of the code used by BTREE indexes, omitting the parts irrelevant for BRIN indexes (e.g. uniqueness checks). This also introduces a new index AM flag amcanbuildparallel, determining whether to attempt to start parallel workers for the index build. Original patch by me, with reviews and substantial reworks by Matthias van de Meent, certainly enough to make him a co-author. Author: Tomas Vondra, Matthias van de Meent Reviewed-by: Matthias van de Meent Discussion: https://postgr.es/m/c2ee7d69-ce17-43f2-d1a0-9811edbda6e6%40enterprisedb.com
* doc: clarify handling of ON CONFLICT with triggersBruce Momjian2023-12-07
| | | | | | | | | | | The previous wording was confusing. Also move partitioning mention to a more logical location. Reported-by: neil@fairwindsoft.com Discussion: https://postgr.es/m/20170703200710.27956.64565@wrigleys.postgresql.org Backpatch-through: master
* doc, pg_upgrade: add vacuumdb w/ tips for generating quick statsBruce Momjian2023-12-07
| | | | | | | | Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevEwGBY-W7EkTbjMY1rC+mmRL3fMrnX6YaUkcr+7o9PSa3w@mail.gmail.com Backpatch-through: master
* doc: FOR UPDATE / KEY / SHARE / KEY SHARE takes an table aliasBruce Momjian2023-12-07
| | | | | | | | | | Previously only a table name was documented for this SELECT clause. Reported-by: robert <lists@humanleg.org.uk> Discussion: https://postgr.es/m/152483686904.19805.3369061025704720797@wrigleys.postgresql.org Backpatch-through: master
* doc, intagg: fix one-to-many mention to many-to-manyBruce Momjian2023-12-07
| | | | | | | | | | Reported-by: Christophe Courtois Discussion: https://postgr.es/m/aa7cfd73-0d8d-596a-b684-39faa479afa5@dalibo.com Author: Christophe Courtois Backpatch-through: master
* Add support for REINDEX in event triggersMichael Paquier2023-12-04
| | | | | | | | | | | | | | This commit adds support for REINDEX in event triggers, making this command react for the events ddl_command_start and ddl_command_end. The indexes rebuilt are collected with the ReindexStmt emitted by the caller, for the concurrent and non-concurrent paths. Thanks to that, it is possible to know a full list of the indexes that a single REINDEX command has worked on. Author: Garrett Thornburg, Jian He Reviewed-by: Jim Jones, Michael Paquier Discussion: https://postgr.es/m/CAEEqfk5bm32G7sbhzHbES9WejD8O8DCEOaLkxoBP7HNWxjPpvg@mail.gmail.com
* doc: Remove reference to trigger file regarding promotionMichael Paquier2023-12-04
| | | | | | | | | | | | | | | The wording changed here comes from 991bfe11d28a, when the only way to trigger a promotion was with a trigger file. There are more options to achieve this operation these days, like the SQL function pg_promote() or the command `pg_ctl promote`, so it is confusing to assume that only a trigger file is able to do the work. Note also that promote_trigger_file has been removed as of cd4329d9393f in 16~. Author: Shinya Kato Discussion: https://postgr.es/m/201b08ea29aa61f96162080e75be503c@oss.nttdata.com Backpatch-through: 12
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-08 23:02:51 +0000