aboutsummaryrefslogtreecommitdiff
path: root/doc/src
Commit message (Collapse)AuthorAge
...
* Introduce pluggable APIs for Cumulative StatisticsMichael Paquier2024-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds support in the backend for $subject, allowing out-of-core extensions to plug their own custom kinds of cumulative statistics. This feature has come up a few times into the lists, and the first, original, suggestion came from Andres Freund, about pg_stat_statements to use the cumulative statistics APIs in shared memory rather than its own less efficient internals. The advantage of this implementation is that this can be extended to any kind of statistics. The stats kinds are divided into two parts: - The in-core "builtin" stats kinds, with designated initializers, able to use IDs up to 128. - The "custom" stats kinds, able to use a range of IDs from 128 to 256 (128 slots available as of this patch), with information saved in TopMemoryContext. This can be made larger, if necessary. There are two types of cumulative statistics in the backend: - For fixed-numbered objects (like WAL, archiver, etc.). These are attached to the snapshot and pgstats shmem control structures for efficiency, and built-in stats kinds still do that to avoid any redirection penalty. The data of custom kinds is stored in a first array in snapshot structure and a second array in the shmem control structure, both indexed by their ID, acting as an equivalent of the builtin stats. - For variable-numbered objects (like tables, functions, etc.). These are stored in a dshash using the stats kind ID in the hash lookup key. Internally, the handling of the builtin stats is unchanged, and both fixed and variabled-numbered objects are supported. Structure definitions for builtin stats kinds are renamed to reflect better the differences with custom kinds. Like custom RMGRs, custom cumulative statistics can only be loaded with shared_preload_libraries at startup, and must allocate a unique ID shared across all the PostgreSQL extension ecosystem with the following wiki page to avoid conflicts: https://wiki.postgresql.org/wiki/CustomCumulativeStats This makes the detection of the stats kinds and their handling when reading and writing stats much easier than, say, allocating IDs for stats kinds from a shared memory counter, that may change the ID used by a stats kind across restarts. When under development, extensions can use PGSTAT_KIND_EXPERIMENTAL. Two examples that can be used as templates for fixed-numbered and variable-numbered stats kinds will be added in some follow-up commits, with tests to provide coverage. Some documentation is added to explain how to use this plugin facility. Author: Michael Paquier Reviewed-by: Dmitry Dolgov, Bertrand Drouvot Discussion: https://postgr.es/m/Zmqm9j5EO0I4W8dx@paquier.xyz
* Fix name of "Visual Studio" in documentation.Noah Misch2024-08-02
| | | | | | | | Back-patch to v17, which introduced this. Aleksander Alekseev Discussion: https://postgr.es/m/CAJ7c6TM7ct0EjoCQaLSVYoxxnEw4xCUFebWj77GktWsqEdyCtQ@mail.gmail.com
* Implement pg_wal_replay_wait() stored procedureAlexander Korotkov2024-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | pg_wal_replay_wait() is to be used on standby and specifies waiting for the specific WAL location to be replayed. This option is useful when the user makes some data changes on primary and needs a guarantee to see these changes are on standby. The queue of waiters is stored in the shared memory as an LSN-ordered pairing heap, where the waiter with the nearest LSN stays on the top. During the replay of WAL, waiters whose LSNs have already been replayed are deleted from the shared memory pairing heap and woken up by setting their latches. pg_wal_replay_wait() needs to wait without any snapshot held. Otherwise, the snapshot could prevent the replay of WAL records, implying a kind of self-deadlock. This is why it is only possible to implement pg_wal_replay_wait() as a procedure working without an active snapshot, not a function. Catversion is bumped. Discussion: https://postgr.es/m/eb12f9b03851bb2583adab5df9579b4b%40postgrespro.ru Author: Kartyshov Ivan, Alexander Korotkov Reviewed-by: Michael Paquier, Peter Eisentraut, Dilip Kumar, Amit Kapila Reviewed-by: Alexander Lakhin, Bharath Rupireddy, Euler Taveira Reviewed-by: Heikki Linnakangas, Kyotaro Horiguchi
* pg_createsubscriber: Rename option --socket-directory to --socketdirPeter Eisentraut2024-08-01
| | | | | | | | For consistency with the equivalent option in pg_upgrade. Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Euler Taveira <euler@eulerto.com> Discussion: https://www.postgresql.org/message-id/flat/1ed82b9b-8e20-497d-a2f8-aebdd793d595%40eisentraut.org
* Convert node test compile-time settings into run-time parametersPeter Eisentraut2024-08-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This converts COPY_PARSE_PLAN_TREES WRITE_READ_PARSE_PLAN_TREES RAW_EXPRESSION_COVERAGE_TEST into run-time parameters debug_copy_parse_plan_trees debug_write_read_parse_plan_trees debug_raw_expression_coverage_test They can be activated for tests using PG_TEST_INITDB_EXTRA_OPTS. The compile-time symbols are kept for build farm compatibility, but they now just determine the default value of the run-time settings. Furthermore, support for these settings is not compiled in at all unless assertions are enabled, or the new symbol DEBUG_NODE_TESTS_ENABLED is defined at compile time, or any of the legacy compile-time setting symbols are defined. So there is no run-time overhead in production builds. (This is similar to the handling of DISCARD_CACHES_ENABLED.) Discussion: https://www.postgresql.org/message-id/flat/30747bd8-f51e-4e0c-a310-a6e2c37ec8aa%40eisentraut.org
* Doc: mention executor memory usage for enable_partitionwise* GUCsDavid Rowley2024-08-01
| | | | | | | | | | | | | | | | | | | Prior to this commit, the docs for enable_partitionwise_aggregate and enable_partitionwise_join mentioned the additional overheads enabling these causes for the query planner, but they mentioned nothing about the possible surge in work_mem-consuming executor nodes that could end up in the final plan. Dimitrios reported the OOM killer intervened on his query as a result of using enable_partitionwise_aggregate=on. Here we adjust the docs to mention the possible increase in the number of work_mem-consuming executor nodes that can appear in the final plan as a result of enabling these GUCs. Reported-by: Dimitrios Apostolou Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/3603c380-d094-136e-e333-610914fb3e80%40gmx.net Discussion: https://postgr.es/m/CAApHDvoZ0_yqwPFEpb6h261L76BUpmh5GxBQq0LeRzQ5Jh3zzg@mail.gmail.com Backpatch-through: 12, oldest supported version
* Add API and ABI stability guidance to the C language docsPeter Eisentraut2024-07-31
| | | | | | | | | Includes guidance for major and minor version releases, and sets reasonable expectations for extension developers to follow. Author: David Wheeler, Peter Eisentraut Discussion: https://www.postgresql.org/message-id/flat/5DA9F9D2-B8B2-43DE-BD4D-53A4160F6E8D%40justatheory.com
* doc: Avoid too prominent use of "backup" on pg_dump man pagePeter Eisentraut2024-07-31
| | | | | | | | | | | | | | Some users inadvertently rely on pg_dump as their primary backup tool, when better solutions exist. The pg_dump man page is arguably misleading in that it starts with "pg_dump is a utility for backing up a PostgreSQL database." This tones this down a little bit, by replacing most uses of "backup" with "export" and adding a short note that pg_dump is not a general-purpose backup tool. Discussion: https://www.postgresql.org/message-id/flat/70b48475-7706-4268-990d-fd522b038d96%40eisentraut.org
* Remove --disable-atomics, require 32 bit atomics.Thomas Munro2024-07-30
| | | | | | | | | | | | | | | | | Modern versions of all relevant architectures and tool chains have atomics support. Since edadeb07, there is no remaining reason to carry code that simulates atomic flags and uint32 imperfectly with spinlocks. 64 bit atomics are still emulated with spinlocks, if needed, for now. Any modern compiler capable of implementing C11 <stdatomic.h> must have the underlying operations we need, though we don't require C11 yet. We detect certain compilers and architectures, so hypothetical new systems might need adjustments here. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (concept, not the patch) Reviewed-by: Andres Freund <andres@anarazel.de> (concept, not the patch) Discussion: https://postgr.es/m/3351991.1697728588%40sss.pgh.pa.us
* Remove --disable-spinlocks.Thomas Munro2024-07-30
| | | | | | | | | | A later change will require atomic support, so it wouldn't make sense for a hypothetical new system not to be able to implement spinlocks. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (concept, not the patch) Reviewed-by: Andres Freund <andres@anarazel.de> (concept, not the patch) Discussion: https://postgr.es/m/3351991.1697728588%40sss.pgh.pa.us
* Doc: fix text's description of regexp_replace's arguments.Tom Lane2024-07-27
| | | | | | | | | | Section 9.7.3 had a syntax synopsis for regexp_replace() that was different from Table 9.10's, but still wrong. Update that one too. Oversight in 580f8727c. Jian He Discussion: https://postgr.es/m/CACJufxG3NFKKsh6x4fRLv8h3V-HvN4W5dA=zNKMxsNcDwOKang@mail.gmail.com
* Introduce num_os_semaphores GUC.Nathan Bossart2024-07-26
| | | | | | | | | | | | | | | | | | | The documentation for System V IPC parameters provides complicated formulas to determine the appropriate values for SEMMNI and SEMMNS. Furthermore, these formulas have often been wrong because folks forget to update them (e.g., when adding a new auxiliary process). This commit introduces a new runtime-computed GUC named num_os_semaphores that reports the number of semaphores needed for the configured number of allowed connections, worker processes, etc. This new GUC allows us to simplify the formulas in the documentation, and it should help prevent future inaccuracies. Like the other runtime-computed GUCs, users can view it with "postgres -C" before starting the server, which is useful for preconfiguring the necessary operating system resources. Reviewed-by: Tom Lane, Sami Imseih, Andres Freund, Robert Haas Discussion: https://postgr.es/m/20240517164452.GA1914161%40nathanxps13
* Clarify error message and documentation related to typed tables.Tom Lane2024-07-26
| | | | | | | | | | | | | | We restrict typed tables (those declared as "OF composite_type") to be based on stand-alone composite types, not composite types that are the implicitly-created rowtypes of other tables. But if you tried to do that, you got the very confusing error message "type foo is not a composite type". Provide a more specific message for that case. Also clarify related documentation in the CREATE TABLE man page. Erik Wienhold and David G. Johnston, per complaint from Hannu Krosing. Discussion: https://postgr.es/m/CAMT0RQRysCb_Amy5CTENSc5GfsvXL1a4qX3mv_hx31_v74P==g@mail.gmail.com
* postgres_fdw: Add connection status check to postgres_fdw_get_connections().Fujii Masao2024-07-26
| | | | | | | | | | | | | | | | | | This commit extends the postgres_fdw_get_connections() function to check if connections are closed. This is useful for detecting closed postgres_fdw connections that could prevent successful transaction commits. Users can roll back transactions immediately upon detecting closed connections, avoiding unnecessary processing of failed transactions. This feature is available only on systems supporting the non-standard POLLRDHUP extension to the poll system call, including Linux. Author: Hayato Kuroda Reviewed-by: Shinya Kato, Zhihong Yu, Kyotaro Horiguchi, Andres Freund Reviewed-by: Onder Kalaci, Takamichi Osumi, Vignesh C, Tom Lane, Ted Yu Reviewed-by: Katsuragi Yuta, Peter Smith, Shubham Khanna, Fujii Masao Discussion: https://postgr.es/m/TYAPR01MB58662809E678253B90E82CE5F5889@TYAPR01MB5866.jpnprd01.prod.outlook.com
* postgres_fdw: Add "used_in_xact" column to postgres_fdw_get_connections().Fujii Masao2024-07-26
| | | | | | | | | | | | | | | | | | | | | | This commit extends the postgres_fdw_get_connections() function to include a new used_in_xact column, indicating whether each connection is used in the current transaction. This addition is particularly useful for the upcoming feature that will check if connections are closed. By using those information, users can verify if postgres_fdw connections used in a transaction remain open. If any connection is closed, the transaction cannot be committed successfully. In this case users can roll back it immediately without waiting for transaction end. The SQL API for postgres_fdw_get_connections() is updated by this commit and may change in the future. To handle compatibility with older SQL declarations, an API versioning system is introduced, allowing the function to behave differently based on the API version. Author: Hayato Kuroda Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/be9382f7-5072-4760-8b3f-31d6dffa8d62@oss.nttdata.com
* Add test for early backend startup errorsHeikki Linnakangas2024-07-26
| | | | | | | | | | | | | | | | The new test tests the libpq fallback behavior on an early error, which was fixed in the previous commit. This adds an IS_INJECTION_POINT_ATTACHED() macro, to allow writing injected test code alongside the normal source code. In principle, the new test could've been implemented by an extra test module with a callback that sets the FrontendProtocol global variable, but I think it's more clear to have the test code right where the injection point is, because it has pretty intimate knowledge of the surrounding context it runs in. Reviewed-by: Michael Paquier Discussion: https://www.postgresql.org/message-id/CAOYmi%2Bnwvu21mJ4DYKUa98HdfM_KZJi7B1MhyXtnsyOO-PB6Ww%40mail.gmail.com
* doc: Enhance documentation for postgres_fdw_get_connections() output columns.Fujii Masao2024-07-26
| | | | | | | | | | | | | | The documentation previously described the output columns of postgres_fdw_get_connections() in text format, which was manageable for the original two columns. However, upcoming patches will add new columns, making text descriptions less readable. This commit updates the documentation to use a table format, making it easier for users to understand each output column. Author: Fujii Masao, Hayato Kuroda Reviewed-by: Hayato Kuroda Discussion: https://postgr.es/m/d04aae8d-05f5-42f4-a263-b962334d9f75@oss.nttdata.com
* Doc: fix misleading syntax synopses for targetlists.Tom Lane2024-07-25
| | | | | | | | | | | In the syntax synopses for SELECT, INSERT, UPDATE, etc, SELECT ... and RETURNING ... targetlists were missing { ... } braces around an OR (|) operator. That allows misinterpretation which could lead to confusion. David G. Johnston, per gripe from masondeanm@aol.com. Discussion: https://postgr.es/m/172193970148.915373.2403176471224676074@wrigleys.postgresql.org
* Doc: update some HTTP links to point to canonical URLs.Tom Lane2024-07-25
| | | | | | | | | These aren't actually broken at present, but we might as well avoid redirects. Joel Jacobson Discussion: https://postgr.es/m/8ccc96c7-0515-491b-be98-cfacdaeda815@app.fastmail.com
* Document restrictions regarding incremental backups and standbys.Robert Haas2024-07-25
| | | | | | | | | | | If you try to take an incremental backup on a standby and there hasn't been much system activity, it might fail. Document why this happens. Also add a hint to the error message you get, to make it more likely that users will understand what has gone wrong. Laurenz Albe and Robert Haas Discussion: https://postgr.es/m/5468641ad821dad7aa3b2d65bf843146443a1b68.camel@cybertec.at
* Add argument names to the regexp_XXX functions.Tom Lane2024-07-25
| | | | | | | | | | | | | | | | | | | | | This change allows these functions to be called using named-argument notation, which can be helpful for readability, particularly for the ones with many arguments. There was considerable debate about exactly which names to use, but in the end we settled on the names already shown in our documentation table 9.10. The citext extension provides citext-aware versions of some of these functions, so add argument names to those too. In passing, fix table 9.10's syntax synopses for regexp_match, which were slightly wrong about which combinations of arguments are allowed. Jian He, reviewed by Dian Fay and others Discussion: https://postgr.es/m/CACJufxG3NFKKsh6x4fRLv8h3V-HvN4W5dA=zNKMxsNcDwOKang@mail.gmail.com
* Add path column to pg_backend_memory_contexts viewDavid Rowley2024-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | "path" provides a reliable method of determining the parent/child relationships between memory contexts. Previously this could be done in a non-reliable way by writing a recursive query and joining the "parent" and "name" columns. This wasn't reliable as the names were not unique, which could result in joining to the wrong parent. To make this reliable, "path" stores an array of numerical identifiers starting with the identifier for TopLevelMemoryContext. It contains an element for each intermediate parent between that and the current context. Incompatibility: Here we also adjust the "level" column to make it 1-based rather than 0-based. A 1-based level provides a convenient way to access elements in the "path" array. e.g. path[level] gives the identifier for the current context. Identifiers are not stable across multiple evaluations of the view. In an attempt to make these more stable for ad-hoc queries, the identifiers are assigned breadth-first. Contexts closer to TopLevelMemoryContext are less likely to change between queries and during queries. Author: Melih Mutlu <m.melihmutlu@gmail.com> Discussion: https://postgr.es/m/CAGPVpCThLyOsj3e_gYEvLoHkr5w=tadDiN_=z2OwsK3VJppeBA@mail.gmail.com Reviewed-by: Andres Freund, Stephen Frost, Atsushi Torikoshi, Reviewed-by: Michael Paquier, Robert Haas, David Rowley
* doc: Decorate psql page with application markup tagsMichael Paquier2024-07-25
| | | | | Noticed while looking at this area of the documentation for a separate patch.
* Fix a missing article in the documentationAlvaro Herrera2024-07-24
| | | | | | | | | Per complaint from Grant Gryczan. It's a very old typo; backpatch all the way back. Author: Laurenz Albe <laurenz.albe@cybertec.at> Discussion: https://postgr.es/m/172179789219.915368.16590585529628354757@wrigleys.postgresql.org
* Doc: Fix the mistakes in the subscription's failover option.Amit Kapila2024-07-24
| | | | | | | | | | | | | The documentation incorrectly stated that users could not alter the subscription's failover option when the two-phase commit is enabled. The steps to confirm that the standby server is ready for failover were incorrect. Author: Shveta Malik, Hou Zhijie Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/OS0PR01MB571657B72F8D75BD858DCCE394AD2@OS0PR01MB5716.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/CAJpy0uBBk+OZXXqQ00Gai09XR+mDi2=9sMBYY0F+BedoFivaMA@mail.gmail.com
* Allow altering of two_phase option of a SUBSCRIPTION.Amit Kapila2024-07-24
| | | | | | | | | | | | | | | | | | | | The two_phase option is controlled by both the publisher (as a slot option) and the subscriber (as a subscription option), so the slot option must also be modified. Changing the 'two_phase' option for a subscription from 'true' to 'false' is permitted only when there are no pending prepared transactions corresponding to that subscription. Otherwise, the changes of already prepared transactions can be replicated again along with their corresponding commit leading to duplicate data or errors. To avoid data loss, the 'two_phase' option for a subscription can only be changed from 'false' to 'true' once the initial data synchronization is completed. Therefore this is performed later by the logical replication worker. Author: Hayato Kuroda, Ajin Cherian, Amit Kapila Reviewed-by: Peter Smith, Hou Zhijie, Amit Kapila, Vitaly Davydov, Vignesh C Discussion: https://postgr.es/m/8fab8-65d74c80-1-2f28e880@39088166
* ldapurl is supported with simple bindPeter Eisentraut2024-07-23
| | | | | | | | | | | | | | | The docs currently imply that ldapurl is for search+bind only, but that's not true. Rearrange the docs to cover this better. Add a test ldapurl with simple bind. This was previously allowed but unexercised, and now that it's documented it'd be good to pin the behavior. Improve error when mixing LDAP bind modes. The option names had gone stale; replace them with a more general statement. Author: Jacob Champion <jacob.champion@enterprisedb.com> Discussion: https://www.postgresql.org/message-id/flat/CAOYmi+nyg9gE0LeP=xQ3AgyQGR=5ZZMkVVbWd0uR8XQmg_dd5Q@mail.gmail.com
* Doc: improve description of plpgsql's FETCH and MOVE commands.Tom Lane2024-07-22
| | | | | | | | | | | | | | | | | | | | | We were not being clear about which variants of the "direction" clause are permitted in MOVE. Also, the text seemed to be written with only the FETCH/MOVE NEXT case in mind, so it didn't apply very well to other variants. Also, document that "MOVE count IN cursor" only works if count is a constant. This is not the whole truth, because some other cases such as a parenthesized expression will also work, but we want to push people to use "MOVE FORWARD count" instead. The constant case is enough to cover what we allow in plain SQL, and that seems sufficient to claim support for. Update a comment in pl_gram.y claiming that we don't document that point. Per gripe from Philipp Salvisberg. Discussion: https://postgr.es/m/172155553388.702.7932496598218792085@wrigleys.postgresql.org
* Doc: improve description of plpgsql's RAISE command.Tom Lane2024-07-18
| | | | | | | | | | | | | RAISE accepts either = or := in the USING clause, so fix the syntax synopsis to show that. Rearrange and wordsmith the descriptions of the different syntax variants, in hopes of improving clarity. Igor Gnatyuk, reviewed by Jian He and Laurenz Albe; minor additional wordsmithing by me Discussion: https://postgr.es/m/CAEu6iLvhF5sdGeat2x4_L0FvWW_SiN--ma8ya7CZd-oJoV+yqQ@mail.gmail.com
* Do not summarize WAL if generated with wal_level=minimal.Robert Haas2024-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | To do this, we must include the wal_level in the first WAL record covered by each summary file; so add wal_level to struct Checkpoint and the payload of XLOG_CHECKPOINT_REDO and XLOG_END_OF_RECOVERY. This, in turn, requires bumping XLOG_PAGE_MAGIC and, since the Checkpoint is also stored in the control file, also PG_CONTROL_VERSION. It's not great to do that so late in the release cycle, but the alternative seems to ship v17 without robust protections against this scenario, which could result in corrupted incremental backups. A side effect of this patch is that, when a server with wal_level=replica is started with summarize_wal=on for the first time, summarization will no longer begin with the oldest WAL that still exists in pg_wal, but rather from the first checkpoint after that. This change should be harmless, because a WAL summary for a partial checkpoint cycle can never make an incremental backup possible when it would otherwise not have been. Report by Fujii Masao. Patch by me. Review and/or testing by Jakub Wartak and Fujii Masao. Discussion: http://postgr.es/m/6e30082e-041b-4e31-9633-95a66de76f5d@oss.nttdata.com
* Add INJECTION_POINT_CACHED() to run injection points directly from cacheMichael Paquier2024-07-18
| | | | | | | | | | | | | | | | | | | | | | This new macro is able to perform a direct lookup from the local cache of injection points (refreshed each time a point is loaded or run), without touching the shared memory state of injection points at all. This works in combination with INJECTION_POINT_LOAD(), and it is better than INJECTION_POINT() in a critical section due to the fact that it would avoid all memory allocations should a concurrent detach happen since a LOAD(), as it retrieves a callback from the backend-private memory. The documentation is updated to describe in more details how to use this new macro with a load. Some tests are added to the module injection_points based on a new SQL function that acts as a wrapper of INJECTION_POINT_CACHED(). Based on a suggestion from Heikki Linnakangas. Author: Heikki Linnakangas, Michael Paquier Discussion: https://postgr.es/m/58d588d0-e63f-432f-9181-bed29313dece@iki.fi
* Doc: fix minor syntax error in example.Tom Lane2024-07-17
| | | | | | | | | The CREATE TABLE option is GENERATED BY DEFAULT *AS* IDENTITY. Per bug #18543 from Ondřej Navrátil. Seems to have crept in in a37bb7c13, so back-patch to v17 where that was added. Discussion: https://postgr.es/m/18543-93c721689f9928e8@postgresql.org
* SQL/JSON: Fix a paragraph in JSON_TABLE documentationAmit Langote2024-07-16
| | | | | | | | | | | | Using <replaceable>text</replaceable> inside parantheses is not a common or good style, so rephrase a sentence to avoid that style. Also rephrase the text in that paragraph a bit while at it. Reported-by: Marcos Pegoraro <marcos@f10.com.br> Author: Jian He <jian.universality@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/CAB-JLwZqH3Yec6Kz-4-+pa0ZG9QJBsxjJZwYcMZYzEDR_fXnKw@mail.gmail.com
* Doc: minor improvements for plpgsql "Transaction Management" section.Tom Lane2024-07-15
| | | | | | | | | | | | | | | | | | Point out that savepoint commands cannot be issued in PL/pgSQL, and suggest that exception blocks can usually be used instead. Add a caveat to the discussion of cursor loops vs. transactions, pointing out that any locks taken by the cursor query will be lost at COMMIT. This is implicit in what's already said, but the existing text leaves the distinct impression that the auto-hold behavior is transparent, which it's not really. Per a couple of recent complaints (one unsigned, and one in bug #18531 from Dzmitry Jachnik). Back-patch to v17, just so this makes it into current docs in less than a year-and-a-half. Discussion: https://postgr.es/m/172076354433.736586.14347210271966220018@wrigleys.postgresql.org Discussion: https://postgr.es/m/18531-c6dddd33b8555fd2@postgresql.org
* Fix tablespace handling in MERGE/SPLIT partition commands.Fujii Masao2024-07-15
| | | | | | | | | | | | | | | As commit ca4103025d stated, new partitions without a specified tablespace should inherit the parent relation's tablespace. However, previously, ALTER TABLE MERGE PARTITIONS and ALTER TABLE SPLIT PARTITION commands always created new partitions in the default tablespace, ignoring the parent's tablespace. This commit ensures new partitions inherit the parent's tablespace. Backpatch to v17 where these commands were introduced. Author: Fujii Masao Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/abaf390b-3320-40a5-8815-ef476db5cfe7@oss.nttdata.com
* Add min and max aggregates for composite types (records).Tom Lane2024-07-11
| | | | | | | | | Like min/max for arrays, these are just thin wrappers around the existing btree comparison function for records. Aleksander Alekseev Discussion: https://postgr.es/m/CAO=iB8L4WYSNxCJ8GURRjQsrXEQ2-zn3FiCsh2LMqvWq2WcONg@mail.gmail.com
* Revamp documentation for predefined roles.Nathan Bossart2024-07-10
| | | | | | | | | | | | | | | | | | | | | | Presently, the page for predefined roles contains a table with brief descriptions of what each role allows. Below the table, there is a separate section with more detailed information about some of the roles. As the set of predefined roles has grown over the years, this page has (IMHO) become less readable. This commit attempts to improve the predefined roles documentation by abandoning the table in favor of listing each role with its own complete description, similar to how we document GUCs. Besides merging the information that was split between the table and the section below it, this commit also alphabetizes the roles. The alphabetization is imperfect because some of the roles are grouped (e.g., pg_read_all_data and pg_write_all_data), and we order such groups by the first role mentioned, but that seemed like a better choice than breaking the groups apart. Finally, this commit makes some stylistic adjustments to the text. Reviewed-by: David G. Johnston, Robert Haas Discussion: https://postgr.es/m/ZmtM-4-eRtq8DRf6%40nathan
* doc: Update track_io_timing documentation to mention pg_stat_io.Fujii Masao2024-07-10
| | | | | | | | | | | | | | | | | | The I/O timing information collected when track_io_timing is enabled is now documented to appear in the pg_stat_io view, which was previously not mentioned. This commit also enhances the description of track_io_timing to clarify that it monitors not only block read and write but also block extend and fsync operations. Additionally, the description of track_wal_io_timing has been improved to mention both WAL write and WAL fsync monitoring. Backpatch to v16 where pg_stat_io was added. Author: Hajime Matsunaga Reviewed-by: Melanie Plageman, Nazir Bilal Yavuz, Fujii Masao Discussion: https://postgr.es/m/TYWPR01MB10742EE4A6F34C33061429D38A4D52@TYWPR01MB10742.jpnprd01.prod.outlook.com
* Extend pg_get_acl() to handle sub-object IDsMichael Paquier2024-07-10
| | | | | | | | | | | | This patch modifies the pg_get_acl() function to accept a third argument called "objsubid", bringing it on par with similar functions in this area like pg_describe_object(). This enables the retrieval of ACLs for relation attributes when scanning dependencies. Bump catalog version. Author: Joel Jacobson Discussion: https://postgr.es/m/f2539bff-64be-47f0-9f0b-df85d3cc0432@app.fastmail.com
* Introduce pg_signal_autovacuum_worker.Nathan Bossart2024-07-09
| | | | | | | | | | | | | | | | Since commit 3a9b18b309, roles with privileges of pg_signal_backend cannot signal autovacuum workers. Many users treated the ability to signal autovacuum workers as a feature instead of a bug, so we are reintroducing it via a new predefined role. Having privileges of this new role, named pg_signal_autovacuum_worker, only permits signaling autovacuum workers. It does not permit signaling other types of superuser backends. Bumps catversion. Author: Kirill Reshke Reviewed-by: Anthony Leung, Michael Paquier, Andrey Borodin Discussion: https://postgr.es/m/CALdSSPhC4GGmbnugHfB9G0%3DfAxjCSug_-rmL9oUh0LTxsyBfsg%40mail.gmail.com
* SQL/JSON: Various improvements to SQL/JSON query function docsAmit Langote2024-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Remove the keyword SELECT from the examples to be consistent with the examples of other JSON-related functions listed on the same page. 2. Add <synopsis> tags around the functions' syntax definition 3. Capitalize function names in the syntax synopsis and the examples 4. Use <itemizedlist> lists for dividing the descriptions of individual functions into bullet points 5. Significantly rewrite the description of wrapper clauses of JSON_QUERY 6. Significantly rewrite the descriptions of ON ERROR / EMPTY clauses of JSON_QUERY() and JSON_VALUE() functions 7. Add a note about how JSON_VALUE() and JSON_QUERY() differ when returning a JSON null result 8. Move the description of the PASSING clause from the descriptions of individual functions into the top paragraph And other miscellaneous text improvements, typo fixes. Suggested-by: Thom Brown <thom@linux.com> Suggested-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Jian He <jian.universality@gmail.com> Reviewed-by: Erik Rijkers <er@xs4all.nl> Discussion: https://postgr.es/m/CAA-aLv7Dfy9BMrhUZ1skcg=OdqysWKzObS7XiDXdotJNF0E44Q@mail.gmail.com Discussion: https://postgr.es/m/CAKFQuwZNxNHuPk44zDF7z8qZec1Aof10aA9tWvBU5CMhEKEd8A@mail.gmail.com
* Improve PL/Tcl's method for choosing Tcl names of procedures.Tom Lane2024-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the internal name of a PL/Tcl function was just "__PLTcl_proc_NNNN", where NNNN is the function OID. That's pretty unhelpful when reading an error report. Plus it prevents us from testing the CONTEXT output for PL/Tcl errors, since the OIDs shown in the regression tests wouldn't be stable. Instead, base the internal name on the result of format_procedure(), which will be unique in most cases. For the edge cases where it's not, we can append the function OID to make it unique. Sadly, the pltcl_trigger.sql test script still has to suppress the context reports, because they'd include trigger arguments which contain relation OIDs per PL/Tcl's longstanding API for triggers. I had to modify one existing test case to throw a different error than before, because I found that Tcl 8.5 and Tcl 8.6 spell the context message for the original error slightly differently. We might have to make more adjustments in that vein once this gets wider testing. Patch by me; thanks to Pavel Stehule for the idea to use format_procedure() rather than just the proname. Discussion: https://postgr.es/m/890581.1717609350@sss.pgh.pa.us
* Doc: minor improvements for our "Brief History" chapter.Tom Lane2024-07-05
| | | | | | | | | | | | | | | | Add a link to Joe Hellerstein's paper "Looking Back at Postgres", which is quite an interesting take on the history of Postgres. The reference to Appendix E was written when we were still keeping the entire release-note history there, which we stopped doing some years ago when the O(N^2) cost of that started to become apparent. Instead, point to the release note archives on the website. (This per suggestion from Daniel Gustafsson.) In passing, move the "ports12" biblioentry to be in alphabetical order within that section. Discussion: https://postgr.es/m/3345678.1720071633@sss.pgh.pa.us
* Support loading of injection pointsMichael Paquier2024-07-05
| | | | | | | | | | | | | | | | | | | This can be used to load an injection point and prewarm the backend-level cache before running it, to avoid issues if the point cannot be loaded due to restrictions in the code path where it would be run, like a critical section where no memory allocation can happen (load_external_function() can do allocations when expanding a library name). Tests can use a macro called INJECTION_POINT_LOAD() to load an injection point. The test module injection_points gains some tests, and a SQL function able to load an injection point. Based on a request from Andrey Borodin, who has implemented a test for multixacts requiring this facility. Reviewed-by: Andrey Borodin Discussion: https://postgr.es/m/ZkrBE1e2q2wGvsoN@paquier.xyz
* Doc: small improvements in discussion of geometric data types.Tom Lane2024-07-04
| | | | | | | | | | | | | | State explicitly that the coordinates in our geometric data types are float8. Also explain that polygons store their bounding box. While here, fix the table of geometric data types to show type "line"'s size correctly: it's 24 bytes not 32. This has somehow escaped notice since that table was made in 1998. Per suggestion from Sebastian Skałacki. The size error seems important enough to justify back-patching. Discussion: https://postgr.es/m/172000045661.706.1822177575291548794@wrigleys.postgresql.org
* doc: Specify when ssl_prefer_server_ciphers was addedDaniel Gustafsson2024-07-04
| | | | | | | | | | | | | | | The ssl_prefer_server_ciphers setting is quite important from a security point of view, so simply stating that older versions doesn't have it isn't very helpful. This adds the version when the GUC was added to help readers. Backpatch to all supported versions since this setting has been around since 9.4. Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/5D7E0F5E-E620-4D54-8788-66D421AC76F0@yesql.se Backpatch-through: v12
* Add pg_get_acl() to get the ACL for a database objectMichael Paquier2024-07-04
| | | | | | | | | | | | | | | | This function returns the ACL for a database object, specified by catalog OID and object OID. This is useful to be able to retrieve the ACL associated to an object specified with a (class_id,objid) couple, similarly to the other functions for object identification, when joined with pg_depend or pg_shdepend. Original idea by Álvaro Herrera. Bump catalog version. Author: Joel Jacobson Reviewed-by: Isaac Morland, Michael Paquier, Ranier Vilela Discussion: https://postgr.es/m/80b16434-b9b1-4c3d-8f28-569f21c2c102@app.fastmail.com
* Remove support for HPPA (a/k/a PA-RISC) architecture.Tom Lane2024-07-01
| | | | | | | | | | | | | | | | | This old CPU architecture hasn't been produced in decades, and whatever instances might still survive are surely too underpowered for anyone to consider running Postgres on in production. We'd nonetheless continued to carry code support for it (largely at my insistence), because its unique implementation of spinlocks seemed like a good edge case for our spinlock infrastructure. However, our last buildfarm animal of this type was retired last year, and it seems quite unlikely that another will emerge. Without the ability to run tests, the argument that this is useful test code fails to hold water. Furthermore, carrying code support for an untestable architecture has costs not to be ignored. So, remove HPPA-specific code, in the same vein as commits 718aa43a4 and 92d70b77e. Discussion: https://postgr.es/m/3351991.1697728588@sss.pgh.pa.us
* Add context type field to pg_backend_memory_contextsDavid Rowley2024-07-01
| | | | | | | | | Since we now (as of v17) have 4 MemoryContext types, the type of context seems like useful information to include in the pg_backend_memory_contexts view. Here we add that. Reviewed-by: David Christensen, Michael Paquier Discussion: https://postgr.es/m/CAApHDvrXX1OR09Zjb5TnB0AwCKze9exZN%3D9Nxxg1ZCVV8W-3BA%40mail.gmail.com
* doc: Clarify that pg_attrdef also stores generation expressionsPeter Eisentraut2024-07-01
| | | | | | | This was documented with pg_attribute but not with pg_attrdef. Reported-by: jian he <jian.universality@gmail.com> Discussion: https://www.postgresql.org/message-id/CACJufxE+E-iYmBnZVZHiYA+WpyZZVv7BfiBLpo=T70EZHDU9rw@mail.gmail.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-26 05:53:23 +0000