summaryrefslogtreecommitdiff
path: root/doc/src
AgeCommit message (Collapse)Author
2021-07-01doc: Remove inappropriate <acronym> tagsPeter Eisentraut
2021-07-01add missing tag from commit b8c4261e5eAndrew Dunstan
2021-07-01doc: Clean up title case usePeter Eisentraut
2021-07-01Add new make targets world-bin and install-world-binAndrew Dunstan
These are the same as world and install-world respectively, but without building or installing the documentation. There are many reasons for wanting to be able to do this, including speed, lack of documentation building tools, and wanting to build other formats of the documentation. Plans for simplifying the buildfarm client code include using these targets. Backpatch to all live branches. Discussion: https://postgr.es/m/6a421136-d462-b043-a8eb-e75b2861f3df@dunslane.net
2021-07-01Add --clobber-cache option to initdb, for CCA testing.Tom Lane
Commit 4656e3d66 replaced the "#define CLOBBER_CACHE_ALWAYS" testing mechanism with a GUC, which has been a great help for doing cache-clobber testing in more efficient ways; but there is a gap in the implementation. The only way to do cache-clobber testing during an initdb run is to use the old method with #define, because one can't set the GUC from outside. Improve this by adding a switch to initdb for the purpose. (Perhaps someday we should let initdb pass through arbitrary "-c NAME=VALUE" switches. Quoting difficulties dissuaded me from attempting that right now, though.) Back-patch to v14 where 4656e3d66 came in. Discussion: https://postgr.es/m/1582507.1624227029@sss.pgh.pa.us
2021-07-01Allow specifying pg_waldump --rmgr option multiple times.Heikki Linnakangas
Before, if you specified multiple --rmgr options, only the last one took effect. It seems more sensible to select all the specified resource managers. Reviewed-By: Daniel Gustafsson, Julien Rouhaud Discussion: https://www.postgresql.org/message-id/98344bc2-e222-02ad-a75b-81ffc614c155%40iki.fi
2021-06-30doc: Improve descriptions of tup_returned and tup_fetched in pg_stat_databaseFujii Masao
Previously the descriptions of tup_returned and tup_fetched columns in pg_stat_database view were confusing. This commit improves them so that they represent the following formulas of those columns more accurately. * pg_stat_database.tup_returned = sum(pg_stat_all_tables.seq_tup_read) + sum(pg_stat_all_indexes.idx_tup_read) * pg_stat_database.tup_fetched = sum(pg_stat_all_tables.idx_tup_fetch) In these formulas, note that the counters for some system catalogs like pg_database shared across all databases of a cluster are excluded from the calculations of sum. Author: Masahiro Ikeda Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/9eeeccdb-5dd7-90f9-2807-a4b5d2b76ca3@oss.nttdata.com
2021-06-30doc: Add type information for postgres_fdw parameters.Fujii Masao
Author: Shinya Kato Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/TYAPR01MB2896DEB25C3B0D57F6139768C40F9@TYAPR01MB2896.jpnprd01.prod.outlook.com
2021-06-30Allow enabling two-phase option via replication protocol.Amit Kapila
Extend the replication command CREATE_REPLICATION_SLOT to support the TWO_PHASE option. This will allow decoding commands like PREPARE TRANSACTION, COMMIT PREPARED and ROLLBACK PREPARED for slots created with this option. The decoding of the transaction happens at prepare command. This patch also adds support of two-phase in pg_recvlogical via a new option --two-phase. This option will also be used by future patches that allow streaming of transactions at prepare time for built-in logical replication. With this, the out-of-core logical replication solutions can enable replication of two-phase transactions via replication protocol. Author: Ajin Cherian Reviewed-By: Jeff Davis, Vignesh C, Amit Kapila Discussion: https://postgr.es/m/02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru https://postgr.es/m/64b9f783c6e125f18f88fbc0c0234e34e71d8639.camel@j-davis.com
2021-06-30Optimize pg_checksums --enable where checksum is already setMichael Paquier
This commit prevents pg_checksums to do a rewrite of a block if it has no need to, in the case where the computed checksum matches with what's already stored in the block read. This is helpful to accelerate successive runs of the tool when the previous ones got interrupted, for example. The number of blocks and files written is tracked and reported by the tool once finished. Note that the final flush of the data folder happens even if no blocks are written, as it could be possible that a previous interrupted run got stopped while doing a flush. Author: Greg Sabino Mullane Reviewed-by: Paquier Michael, Julien Rouhaud Discussion: https://postgr.es/m/CAKAnmmL+k6goxmVzQJB+0bAR0PN1sgo6GDUXJhyhUmVMze1QAw@mail.gmail.com
2021-06-29Add PQsendFlushRequest to libpqAlvaro Herrera
This new libpq function allows the application to send an 'H' message, which instructs the server to flush its outgoing buffer. This hasn't been needed so far because the Sync message already requests a buffer; and I failed to realize that this was needed in pipeline mode because PQpipelineSync also causes the buffer to be flushed. However, sometimes it is useful to request a flush without establishing a synchronization point. Backpatch to 14, where pipeline mode was introduced in libpq. Reported-by: Boris Kolpackov <boris@codesynthesis.com> Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/202106252350.t76x73nt643j@alvherre.pgsql
2021-06-29Add support for LZ4 with compression of full-page writes in WALMichael Paquier
The logic is implemented so as there can be a choice in the compression used when building a WAL record, and an extra per-record bit is used to track down if a block is compressed with PGLZ, LZ4 or nothing. wal_compression, the existing parameter, is changed to an enum with support for the following backward-compatible values: - "off", the default, to not use compression. - "pglz" or "on", to compress FPWs with PGLZ. - "lz4", the new mode, to compress FPWs with LZ4. Benchmarking has showed that LZ4 outclasses easily PGLZ. ZSTD would be also an interesting choice, but going just with LZ4 for now makes the patch minimalistic as toast compression is already able to use LZ4, so there is no need to worry about any build-related needs for this implementation. Author: Andrey Borodin, Justin Pryzby Reviewed-by: Dilip Kumar, Michael Paquier Discussion: https://postgr.es/m/3037310D-ECB7-4BF1-AF20-01C10BB33A33@yandex-team.ru
2021-06-28Stamp HEAD as 15devel.Andrew Dunstan
Let the hacking begin ...
2021-06-28Change recovery_init_sync_method to PGC_SIGHUP.Thomas Munro
The setting has no effect except during startup. It's still nice to be able to change it dynamically, which is expected to be pretty useful to an admin following crash recovery when restarting the cluster is not so appealing. Per discussions following commits 2941138e6 and 61752afb2. Author: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/20210529192321.GM2082%40telsasoft.com
2021-06-26Doc: update v14 release notes for revert of commit c0cb87fbb.Tom Lane
2021-06-25Doc: remove commit f560209c6 from v14 release notes.Tom Lane
Now that this has been back-patched, it's no longer a new feature for v14.
2021-06-25Put option listing back into alphabetical orderPeter Eisentraut
2021-06-25Fixes in ALTER SUBSCRIPTION DROP PUBLICATION codePeter Eisentraut
ALTER SUBSCRIPTION DROP PUBLICATION does not actually support copy_data option, so remove it from tab completion. Also, reword the error message that is thrown when all the publications from a subscription are specified to be dropped. Also, made few doc and cosmetic adjustments. Author: Vignesh C <vignesh21@gmail.com> Reviewed-by: Bharath Rupireddy <bharath.rupireddy@enterprisedb.com> Reviewed-by: Japin Li <japinli@hotmail.com> Discussion: https://www.postgresql.org/message-id/flat/CALDaNm21RwsDzs4xj14ApteAF7auyyomHNnp+NEL-sH8m-jMvQ@mail.gmail.com
2021-06-25doc: Change reloption data type spelling for consistencyPeter Eisentraut
Use "floating point" rather than "float4", like everywhere else in this context. Author: Shinya11.Kato@nttdata.com Discussion: https://www.postgresql.org/message-id/flat/TYAPR01MB28965989AF84B57FC351B97BC40F9@TYAPR01MB2896.jpnprd01.prod.outlook.com
2021-06-25Doc: Fix minor formatting issue in logicaldecoding.sgml.Amit Kapila
Author: Guillaume Lelarge Discussion: https://www.postgresql.org/message-id/CAECtzeXf3_oZoU6mgFCOy5+pDZ5n4XtH0Da4a5n_KacraVWiHQ@mail.gmail.com
2021-06-25doc: Add acronyms for MITM and SNIMichael Paquier
This adds MITM and SNI as acronyms, as the documentation already had them marked up with <acronym>. While on it, make sure to spell man-in-the-middle with dashes consistently, and add acronyms for those new terms where appropriate. Author: Daniel Gustafsson Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CE12DD5C-4BB3-4166-BC9A-39779568734C@yesql.se
2021-06-25doc: Move remove_temp_files_after_crash to section for developer optionsMichael Paquier
The main goal of this option is to allow inspecting temporary files for debugging purposes, so moving the parameter there is natural. Oversight in cd91de0. Reported-by: Justin Pryzby Author: Euler Taveira Discussion: https://postgr.es/m/20210612004347.GP16435@telsasoft.com
2021-06-24Doc: Update logical replication message formats.Amit Kapila
Commits 9de77b5453 and ac4645c015 missed to update the logical replication message formats section in the docs. Author: Brar Piening Reviewed-by: Amit Kapila Discussion: https://www.postgresql.org/message-id/cc70956c-e578-e54f-49e6-b5d68c89576f@gmx.de
2021-06-24Doc: Update caveats in synchronous logical replication.Amit Kapila
Reported-by: Simon Riggs Author: Takamichi Osumi Reviewed-by: Amit Kapila Backpatch-through: 9.6 Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky@alap3.anarazel.de
2021-06-23Doc: fix confusion about LEAKPROOF in syntax summaries.Tom Lane
The syntax summaries for CREATE FUNCTION and allied commands made it look like LEAKPROOF is an alternative to IMMUTABLE/STABLE/VOLATILE, when of course it is an orthogonal option. Improve that. Per gripe from aazamrafeeque0. Thanks to David Johnston for suggestions. Discussion: https://postgr.es/m/162444349581.694.5818572718530259025@wrigleys.postgresql.org
2021-06-21Finish rename of PQtraceSetFlags() to PQsetTraceFlags().Noah Misch
Jie Zhang Discussion: https://postgr.es/m/TYWPR01MB767844835390EDD8DB276D75F90A9@TYWPR01MB7678.jpnprd01.prod.outlook.com
2021-06-21doc: adjust PG 14 relnotes to be currentBruce Momjian
2021-06-20doc: add mention of +4GB windows file handling in PG14 relnotesBruce Momjian
Reported-by: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoCTHyouoGv-xt1qNjjvPbGMErLi0AJncByTvr66Nq7j8g@mail.gmail.com
2021-06-18Support disabling index bypassing by VACUUM.Peter Geoghegan
Generalize the INDEX_CLEANUP VACUUM parameter (and the corresponding reloption): make it into a ternary style boolean parameter. It now exposes a third option, "auto". The "auto" option (which is now the default) enables the "bypass index vacuuming" optimization added by commit 1e55e7d1. "VACUUM (INDEX_CLEANUP TRUE)" is redefined to once again make VACUUM simply do any required index vacuuming, regardless of how few dead tuples are encountered during the first scan of the target heap relation (unless there are exactly zero). This gives users a way of opting out of the "bypass index vacuuming" optimization, if for whatever reason that proves necessary. It is also expected to be used by PostgreSQL developers as a testing option from time to time. "VACUUM (INDEX_CLEANUP FALSE)" does the same thing as it always has: it forcibly disables both index vacuuming and index cleanup. It's not expected to be used much in PostgreSQL 14. The failsafe mechanism added by commit 1e55e7d1 addresses the same problem in a simpler way. INDEX_CLEANUP can now be thought of as a testing and compatibility option. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/CAH2-WznrBoCST4_Gxh_G9hA8NzGUbeBGnOUC8FcXcrhqsv6OHQ@mail.gmail.com
2021-06-18doc: Apply markup <productname> to OpenSSL more consistentlyMichael Paquier
Author: Daniel Gustafsson Discussion: https://postgr.es/m/CE12DD5C-4BB3-4166-BC9A-39779568734C@yesql.se
2021-06-17Document a few caveats in synchronous logical replication.Amit Kapila
In a synchronous logical setup, locking [user] catalog tables can cause deadlock. This is because logical decoding of transactions can lock catalog tables to access them so exclusively locking those in transactions can lead to deadlock. To avoid this users must refrain from having exclusive locks on catalog tables. Author: Takamichi Osumi Reviewed-by: Vignesh C, Amit Kapila Backpatch-through: 9.6 Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky%40alap3.anarazel.de
2021-06-15Revert 29854ee8d1 due to buildfarm failuresAlexander Korotkov
Reported-by: Tom Lane Discussion: https://postgr.es/m/CAPpHfdvcnw3x7jdV3r52p4%3D5S4WUxBCzcQKB3JukQHoicv1LSQ%40mail.gmail.com
2021-06-15Add missing type name "multirange" in docs chapter titleAlexander Korotkov
Discussion: https://postgr.es/m/CAFj8pRDioOxiJgmgw9TqQqZ3CxnJC4P5B2Oospf2eMgAjJuewA%40mail.gmail.com Author: Pavel Stehule, Alexander Korotkov Reviewed-by: Justin Pryzby, Tom Lane
2021-06-15Support for unnest(multirange) and cast multirange as an array of rangesAlexander Korotkov
It has been spotted that multiranges lack of ability to decompose them into individual ranges. Subscription and proper expanded object representation require substantial work, and it's too late for v14. This commit provides the implementation of unnest(multirange) and cast multirange as an array of ranges, which is quite trivial. unnest(multirange) is defined as a polymorphic procedure. The catalog description of the cast underlying procedure is duplicated for each multirange type because we don't have anyrangearray polymorphic type to use here. Catversion is bumped. Reported-by: Jonathan S. Katz Discussion: https://postgr.es/m/flat/60258efe-bd7e-4886-82e1-196e0cac5433%40postgresql.org Author: Alexander Korotkov Reviewed-by: Justin Pryzby, Jonathan S. Katz, Zhihong Yu
2021-06-14Remove pg_wait_for_backend_termination().Noah Misch
It was unable to wait on a backend that had already left the procarray. Users tolerant of that limitation can poll pg_stat_activity. Other users can employ the "timeout" argument of pg_terminate_backend(). Reviewed by Bharath Rupireddy. Discussion: https://postgr.es/m/20210605013236.GA208701@rfd.leadboat.com
2021-06-14Copy-edit text for the pg_terminate_backend() "timeout" parameter.Noah Misch
Revert the pg_description entry to its v13 form, since those messages usually remain shorter and don't discuss individual parameters. No catversion bump, since pg_description content does not impair backend compatibility or application compatibility. Justin Pryzby Discussion: https://postgr.es/m/20210612182743.GY16435@telsasoft.com
2021-06-14doc: PG 14 relnotes fixesBruce Momjian
Items related to logical replication attribution and BRIN indexes Reported-by: Tomas Vondra, John Naylor Discussion: https://postgr.es/m/0db66294-a668-2caa-2b5e-a8db60b30662@enterprisedb.com, CAFBsxsH21KnteYdk33F1oZu2O726NSD6_XBq51Tn0jytsA1AnA@mail.gmail.com
2021-06-14doc: PG 14 relnote updatesBruce Momjian
Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20210612034551.GU16435@telsasoft.com
2021-06-14doc: add PG 14 relnote item about array function referencesBruce Momjian
User-defined objects that reference some built-in array functions will need to be recreated in PG 14. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20210608225618.GR16435@telsasoft.com
2021-06-14Remove forced toast recompression in VACUUM FULL/CLUSTERMichael Paquier
The extra checks added by the recompression of toast data introduced in bbe0a81 is proving to have a performance impact on VACUUM or CLUSTER even if no recompression is done. This is more noticeable with more toastable columns that contain non-NULL values. Improvements could be done to make those extra checks less expensive, but that's not material for 14 at this stage, and we are not sure either if the code path of VACUUM FULL/CLUSTER is adapted for this job. Per discussion with several people, including Andres Freund, Robert Haas, Álvaro Herrera, Tom Lane and myself. Discussion: https://postgr.es/m/20210527003144.xxqppojoiwurc2iz@alap3.anarazel.de
2021-06-11doc: remove extra right angle bracket in PG 14 relnotesBruce Momjian
Reported-by: Justin Pryzby
2021-06-11docs: fix incorrect indenting in PG 14 relnotesBruce Momjian
2021-06-10Rename PQtraceSetFlags() to PQsetTraceFlags().Noah Misch
We have a dozen PQset*() functions. PQresultSetInstanceData() and this were the libpq setter functions having a different word order. Adopt the majority word order. Reviewed by Alvaro Herrera and Robert Haas, though this choice of name was not unanimous. Discussion: https://postgr.es/m/20210605060555.GA216695@rfd.leadboat.com
2021-06-11Use the correct article for abbreviationsDavid Rowley
We've accumulated quite a mix of instances of "an SQL" and "a SQL" in the documents. It would be good to be a bit more consistent with these. The most recent version of the SQL standard I looked at seems to prefer "an SQL". That seems like a good lead to follow, so here we change all instances of "a SQL" to become "an SQL". Most instances correctly use "an SQL" already, so it also makes sense to use the dominant variation in order to minimise churn. Additionally, there were some other abbreviations that needed to be adjusted. FSM, SSPI, SRF and a few others. Also fix some pronounceable, abbreviations to use "a" instead of "an". For example, "a SASL" instead of "an SASL". Here I've only adjusted the documents and error messages. Many others still exist in source code comments. Translator hint comments seem to be the biggest culprit. It currently does not seem worth the churn to change these. Discussion: https://postgr.es/m/CAApHDvpML27UqFXnrYO1MJddsKVMQoiZisPvsAGhKE_tsKXquw%40mail.gmail.com
2021-06-10Reconsider the handling of procedure OUT parameters.Tom Lane
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of OUT parameters, for procedures only. While that had some advantages for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty disastrous from a number of other perspectives. Notably, since the primary key of pg_proc is name + proargtypes, this made it possible to have multiple procedures with identical names + input arguments and differing output argument types. That would make it impossible to call any one of the procedures by writing just NULL (or "?", or any other data-type-free notation) for the output argument(s). The change also seems likely to cause grave confusion for client applications that examine pg_proc and expect the traditional definition of proargtypes. Hence, revert the definition of proargtypes to what it was, and undo a number of complications that had been added to support that. To support the SQL-spec behavior of DROP PROCEDURE, when there are no argmode markers in the command's parameter list, we perform the lookup both ways (that is, matching against both proargtypes and proallargtypes), succeeding if we get just one unique match. In principle this could result in ambiguous-function failures that would not happen when using only one of the two rules. However, overloading of procedure names is thought to be a pretty rare usage, so this shouldn't cause many problems in practice. Postgres-specific code such as pg_dump can defend against any possibility of such failures by being careful to specify argmodes for all procedure arguments. This also fixes a few other bugs in the area of CALL statements with named parameters, and improves the documentation a little. catversion bump forced because the representation of procedures with OUT arguments changes. Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-08Avoid misbehavior when persisting a non-stable cursor.Tom Lane
PersistHoldablePortal has long assumed that it should store the entire output of the query-to-be-persisted, which requires rewinding and re-reading the output. This is problematic if the query is not stable: we might get different row contents, or even a different number of rows, which'd confuse the cursor state mightily. In the case where the cursor is NO SCROLL, this is very easy to solve: just store the remaining query output, without any rewinding, and tweak the portal's cursor state to match. Aside from removing the semantic problem, this could be significantly more efficient than storing the whole output. If the cursor is scrollable, there's not much we can do, but it was already the case that scrolling a volatile query's result was pretty unsafe. We can just document more clearly that getting correct results from that is not guaranteed. There are already prohibitions in place on using SCROLL with FOR UPDATE/SHARE, which is one way for a SELECT query to have non-stable results. We could imagine prohibiting SCROLL when the query contains volatile functions, but that would be expensive to enforce. Moreover, it could break applications that work just fine, if they have functions that are in fact stable but the user neglected to mark them so. So settle for documenting the hazard. While this problem has existed in some guise for a long time, it got a lot worse in v11, which introduced the possibility of persisting plpgsql cursors (perhaps implicit ones) even when they violate the rules for what can be marked WITH HOLD. Hence, I've chosen to back-patch to v11 but not further. Per bug #17050 from Алексей Булгаков. Discussion: https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org
2021-06-08doc: update release note item about the v2 wire protocolBruce Momjian
Protocol v2 was last used in PG 7.3, not 7.2. Reported-by: Tatsuo Ishii Discussion: https://postgr.es/m/20210608.091329.906837606658882674.t-ishii@sraoss.co.jp
2021-06-08Adjust batch size in postgres_fdw to not use too many parametersTomas Vondra
The FE/BE protocol identifies parameters with an Int16 index, which limits the maximum number of parameters per query to 65535. With batching added to postges_fdw this limit is much easier to hit, as the whole batch is essentially a single query, making this error much easier to hit. The failures are a bit unpredictable, because it also depends on the number of columns in the query. So instead of just failing, this patch tweaks the batch_size to not exceed the maximum number of parameters. Reported-by: Hou Zhijie <houzj.fnst@cn.fujitsu.com> Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Discussion: https://postgr.es/m/OS0PR01MB571603973C0AC2874AD6BF2594299%40OS0PR01MB5716.jpnprd01.prod.outlook.com
2021-06-08Doc: Further update documentation for asynchronous execution.Etsuro Fujita
Add a note about asynchronous execution by postgres_fdw when applied to Append nodes that contain synchronous subplan(s) as well. Follow-up for commit 27e1f1456. Andrey Lepikhov and Etsuro Fujita Discussion: https://postgr.es/m/58fa2aa5-07f5-80b5-59a1-fec8a349fee7%40postgrespro.ru
2021-06-05doc: Simplify COMMENT and SECURITY LABEL documentationPeter Eisentraut
Just say that objects that reside in schemas can be schema-qualified. Don't list all possible such objects. The existing lists weren't complete anyway. Discussion: https://www.postgresql.org/message-id/flat/b2ec2234-67fe-d861-5cea-f526cd18c086%40enterprisedb.com