aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Fix bogus behavior of PQsslAttribute(conn, "library").Tom Lane2022-09-29
| | | | | | | | | | | | Commit ebc8b7d44 intended to change the behavior of PQsslAttribute(NULL, "library"), but accidentally also changed what happens with a non-NULL conn pointer. Undo that so that only the intended behavior change happens. Clarify some associated documentation. Per bug #17625 from Heath Lord. Back-patch to v15. Discussion: https://postgr.es/m/17625-fc47c78b7d71b534@postgresql.org
* Update comment in ExecInsert() regarding batch insertion.Etsuro Fujita2022-09-29
| | | | | | | | | | | | Remove the stale text that is a leftover from an earlier version of the patch to add support for batch insertion, and adjust the wording in the remaining text. Back-patch to v14 where batch insertion came in. Review and wording adjustment by Tom Lane. Discussion: https://postgr.es/m/CAPmGK14goatHPHQv2Aeu_UTKqZ%2BBO%2BP%2Bzd3HKv5D%2BdyyfWKDSw%40mail.gmail.com
* Restrict Datum sort optimization to byval types onlyDavid Rowley2022-09-29
| | | | | | | | | | | | | | | | | | | 91e9e89dc modified nodeSort.c so that it used datum sorts when the targetlist of the outer node contained only a single column. That commit failed to recognise that the Datum returned by tuplesort_getdatum() must be pfree'd when the type is a byref type. Ronan Dunklau did originally propose the patch with that restriction, but that, probably through my own fault, got lost during further development work. Due to the timing of this report (PG15 RC1 is almost out the door), let's just restrict the datum sort optimization to apply for byval types only. We might want to look harder into making this work for byref types in PG16. Reported-by: Önder Kalacı Diagnosis-by: Tom Lane Discussion: https://postgr.es/m/CACawEhVxe0ufR26UcqtU7GYGRuubq3p6ZWPGXL4cxy_uexpAAQ@mail.gmail.com Backpatch-through: 15, where 91e9e89dc was introduced.
* Change some errdetail() to errdetail_internal()Alvaro Herrera2022-09-28
| | | | | | | | | | | | This prevents marking the argument string for translation for gettext, and it also prevents the given string (which is already translated) from being translated at runtime. Also, mark the strings used as arguments to check_rolespec_name for translation. Backpatch all the way back as appropriate. None of this is caught by any tests (necessarily so), so I verified it manually.
* Remove publicationcmds.c's expr_allowed_in_node as a functionAlvaro Herrera2022-09-28
| | | | | | | | Its API is quite strange, and since there's only one caller, there's no reason for it to be a separate function in the first place. Inline it instead. Discussion: https://postgr.es/m/20220927124249.4zdzzlz6had7k3x2@alvherre.pgsql
* Improve some publication-related error messagesAlvaro Herrera2022-09-27
| | | | | | | | | | | While at it, remove an unused queryString parameter from CheckPubRelationColumnList() and make other minor stylistic changes. Backpatch to 15. Reported by Kyotaro Horiguchi <horikyota.ntt@gmail.com> Co-authored-by: Hou zj <houzj.fnst@fujitsu.com> Discussion: https://postgr.es/m/20220926.160426.454497059203258582.horikyota.ntt@gmail.com
* Fix pg_stat_statements for MERGEAlvaro Herrera2022-09-27
| | | | | | | | | | | | We weren't jumbling the merge action list, so wildly different commands would be considered to use the same query ID. Add that, mention it in the docs, and some test lines. Backpatch to 15. Author: Tatsu <bt22nakamorit@oss.nttdata.com> Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://postgr.es/m/d87e391694db75a038abc3b2597828e8@oss.nttdata.com
* ci: Add hint about downloadable logs to READMEAndres Freund2022-09-26
| | | | | | | | | I (Andres) chose to backpatch this to 15, as it seems better to keep the README the same. Author: James Coleman <jtc331@gmail.com> Discussion: https://postgr.es/m/CAAaqYe_7BXDjpk0Ks_eqf1r6LZpC_rfB7kjhb_T3+eC4t6yiGQ@mail.gmail.com Backpatch: 15-, where CI came in
* Translation updatesPeter Eisentraut2022-09-26
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 0a336c1e07ac371cf445a0cecac6b27720da228c
* Fix tupdesc lifespan bug with AfterTriggersTableData.storeslot.Tom Lane2022-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 25936fd46 adjusted things so that the "storeslot" we use for remapping trigger tuples would have adequate lifespan, but it neglected to consider the lifespan of the tuple descriptor that the slot depends on. It turns out that in at least some cases, the tupdesc we are passing is a refcounted tupdesc, and the refcount for the slot's reference can get assigned to a resource owner having different lifespan than the slot does. That leads to an error like "tupdesc reference 0x7fdef236a1b8 is not owned by resource owner SubTransaction". Worse, because of a second oversight in the same commit, we'd try to free the same tupdesc refcount again while cleaning up after that error, leading to recursive errors and an "ERRORDATA_STACK_SIZE exceeded" PANIC. To fix the initial problem, let's just make a non-refcounted copy of the tupdesc we're supposed to use. That seems likely to guard against additional problems, since there's no strong reason for this code to assume that what it's given is a refcounted tupdesc; in which case there's an independent hazard of the tupdesc having shorter lifespan than the slot does. (I didn't bother trying to free said copy, since it should go away anyway when the (sub) transaction context is cleaned up.) The other issue can be fixed by making the code added to AfterTriggerFreeQuery work like the rest of that function, ie be sure that it doesn't try to free the same slot twice in the event of recursive error cleanup. While here, also clean up minor stylistic issues in the test case added by 25936fd46: don't use "create or replace function", as any name collision within the tests is likely to have ill effects that that won't mask; and don't use function names as generic as trigger_function1, especially if you're not going to drop them at the end of the test stanza. Per bug #17607 from Thomas Mc Kay. Back-patch to v12, as the previous fix was. Discussion: https://postgr.es/m/17607-bd8ccc81226f7f80@postgresql.org
* Avoid loss of code coverage with unlogged-index test cases.Tom Lane2022-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4fb5c794e intended to add coverage of some ambuildempty methods that were not getting reached, without removing any test coverage. However, by changing a temp table to unlogged it managed to negate the intent of 4c51a2d1e, which means that we didn't have reliable test coverage of ginvacuum.c anymore. As things stand, much of that file might or might not get reached depending on timing, which seems pretty undesirable. Although this is only clearly broken for the GIN test, it seems best to revert 4fb5c794e altogether and instead add bespoke test cases covering unlogged indexes for these four AMs. We don't need to do very much with them, so the extra tests are cheap. (Note that btree, hash, and bloom already have similar test cases, so they need no additional work.) We can also undo dec8ad367. Since the testing deficiency that that hacked around was later fixed by 2f2e24d90, let's intentionally leave an unlogged table behind to improve test coverage in the modules that use the regression database for other test purposes. (The case I used also leaves an unlogged sequence behind.) Per report from Alex Kozhemyakin. Back-patch to v15 where the faulty test came in. Discussion: https://postgr.es/m/b00c8ee096ee46cd25c183125562a1a7@postgrespro.ru
* Add missing source files to pg_waldump/nls.mkAlvaro Herrera2022-09-25
|
* Message style improvementsPeter Eisentraut2022-09-24
|
* Improve terminologyPeter Eisentraut2022-09-23
| | | | | Use "prepared transaction" instead of "two-phrase transaction". This is in line with c5d67881d343a507269bde124a49df19e0296157.
* pgstat: Fix transactional stats dropping for indexesAndres Freund2022-09-23
| | | | | | | | | | | | | | | | | | | | Because index creation does not go through heap_create_with_catalog() we didn't call pgstat_create_relation(), leading to index stats of a newly created realtion not getting dropped during rollback. To fix, move the pgstat_create_relation() to heap_create(), which indexes do use. Similarly, because dropping an index does not go through heap_drop_with_catalog(), we didn't drop index stats when the transaction dropping an index committed. Here there's no convenient common path for indexes and relations, so index_drop() now calls pgstat_drop_relation(). Add tests for transactional index stats handling. Author: "Drouvot, Bertrand" <bdrouvot@amazon.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/51bbf286-2b4a-8998-bd12-eaae4b765d99@amazon.com Backpatch: 15-, like 8b1dccd37c71, which introduced the bug
* Remove PQsendQuery support in pipeline modeAlvaro Herrera2022-09-23
| | | | | | | | | | | | | | | | | | The extended query protocol implementation I added in commit acb7e4eb6b1c has bugs when used in pipeline mode. Rather than spend more time trying to fix it, remove that code and make the function rely on simple query protocol only, meaning it can no longer be used in pipeline mode. Users can easily change their applications to use PQsendQueryParams instead. We leave PQsendQuery in place for Postgres 14, just in case somebody is using it and has not hit the mentioned bugs; but we should recommend that it not be used. Backpatch to 15. Per bug report from Gabriele Varrazzo. Discussion: https://postgr.es/m/CA+mi_8ZGSQNmW6-mk_iSR4JZB_LJ4ww3suOF+1vGNs3MrLsv4g@mail.gmail.com
* Stop using PQsendQuery in libpq_pipelineAlvaro Herrera2022-09-23
| | | | | | | | | | | | The "emulation" I wrote for PQsendQuery in pipeline mode to use extended query protocol, in commit acb7e4eb6b1c, is problematic. Due to numerous bugs we'll soon remove it. As a first step and for all branches back to 14, stop using PQsendQuery in libpq_pipeline. Also remove a few test lines that will no longer be relevant. Backpatch to 14. Discussion: https://postgr.es/m/CA+mi_8ZGSQNmW6-mk_iSR4JZB_LJ4ww3suOF+1vGNs3MrLsv4g@mail.gmail.com
* Allow publications with schema and table of the same schema.Amit Kapila2022-09-23
| | | | | | | | | | | | | | | | | | | | | We previously thought that allowing such cases can confuse users when they specify DROP TABLES IN SCHEMA but that doesn't seem to be the case based on discussion. This helps to uplift the restriction during ALTER TABLE ... SET SCHEMA which used to ensure that we couldn't end up with a publication having both a schema and the same schema's table. To allow this, we need to forbid having any schema on a publication if column lists on a table are specified (and vice versa). This is because otherwise we still need a restriction during ALTER TABLE ... SET SCHEMA to forbid cases where it could lead to a publication having both a schema and the same schema's table with column list. Based on suggestions by Peter Eisentraut. Author: Hou Zhijie and Vignesh C Reviewed-By: Peter Smith, Amit Kapila Backpatch-through: 15, where it was introduced Discussion: https://postgr.es/m/2729c9e2-9aac-8cda-f2f4-34f2bcc18f4e@enterprisedb.com
* Fix race condition where heap_delete() fails to pin VM page.Jeff Davis2022-09-22
| | | | | | | | | | Similar to 5f12bc94dc, the code must re-check PageIsAllVisible() after buffer lock is re-acquired. Backpatching to the same version, 12. Discussion: https://postgr.es/m/CAEP4nAw9jYQDKd_5Y+-s2E4YiUJq1vqiikFjYGpLShtp-K3gag@mail.gmail.com Reported-by: Robins Tharakan Reviewed-by: Robins Tharakan Backpatch-through: 12
* Remove ALL keyword from TABLES IN SCHEMA for publicationAlvaro Herrera2022-09-22
| | | | | | | | | | | | | | | | | | This may be a bit too subtle, but removing that word from there makes this clause no longer a perfect parallel of the GRANT variant "ALL TABLES IN SCHEMA": indeed, for publications what we record is the schema itself, not the tables therein, which means that any tables added to the schema in the future are also published. This is completely different to what GRANT does, which is affect only the tables that exist when the command is executed. There isn't resounding support for this change, but there are a few positive votes and no opposition. Because the time to 15 RC1 is very short, let's get this out now. Backpatch to 15. Discussion: https://postgr.es/m/2729c9e2-9aac-8cda-f2f4-34f2bcc18f4e
* Use min/max bounds defined by Zstd for compression levelMichael Paquier2022-09-22
| | | | | | | | | | | | | | | | | | The bounds hardcoded in compression.c since ffd5365 (minimum at 1 and maximum at 22) do not match the reality of what zstd is able to handle, these values being available via ZSTD_maxCLevel() and ZSTD_minCLevel() at run-time. The maximum of 22 is actually correct in recent versions, but the minimum was not as the library can go down to -131720 by design. This commit changes the code to use the run-time values in the code instead of some hardcoded ones. Zstd seems to assume that these bounds could change in the future, and Postgres will be able to adapt automatically to such changes thanks to what's being done in this commit. Reported-by: Justin Prysby Discussion: https://postgr.es/m/20220922033716.GL31833@telsasoft.com Backpatch-through: 15
* Fix thinko in comment.Etsuro Fujita2022-09-22
| | | | | | | This comment has been wrong since its introduction in commit 0d5f05cde; backpatch to v12 where that came in. Discussion: https://postgr.es/m/CAPmGK14VGf-xQjGQN4o1QyAbXAaxugU5%3DqfcmTDh1iufUDnV_w%40mail.gmail.com
* Clear ps display of startup process at the end of recoveryMichael Paquier2022-09-22
| | | | | | | | | | | | | | | | | If the ps display is not cleared at this point, the process could continue displaying "recovering NNN" even if handling end-of-recovery steps. df9274a has tackled that by providing some information with the end-of-recovery checkpoint but 7ff23c6 has nullified the effect of the first commit. Per a suggestion from Justin, just clear the ps display when we are done with recovery, so as no incorrect information is displayed. This may get extended in the future, but for now restore the pre-7ff23c6 behavior. Author: Justin Prysby Discussion: https://postgr.es/m/20220913223954.GU31833@telsasoft.com Backpatch-through: 15
* psql: Improve tab-completion for MERGE.Fujii Masao2022-09-22
| | | | | | | | | | | | | Commit 7103ebb7aa added the tab-completion for MERGE accidentally in the middle of that for LOCK TABLE. This commit fixes this issue. This also adds some tab-completion for MERGE. Back-patch to v15 where MERGE was introduced. Author: Kotaro Kawamoto, Fujii Masao Reviewed-by: Shinya Kato, Álvaro Herrera Discussion: https://postgr.es/m/9f1ad2a87a58cd5e7d64f3993130958d@oss.nttdata.com
* Improve ICU option handling in CREATE DATABASEPeter Eisentraut2022-09-21
| | | | | | | | | | We check that the ICU locale is only specified if the ICU locale provider is selected. But we did that too early. We need to wait until we load the settings of the template database, since that could also set what the locale provider is. Reported-by: Marina Polyakova <m.polyakova@postgrespro.ru> Discussion: https://www.postgresql.org/message-id/9ba4cd1ea6ed6b7b15c0ff15e6f540cd@postgrespro.ru
* Tighten pg_get_object_address argument checkingPeter Eisentraut2022-09-21
| | | | | | | | | | | | For publication schemas (OBJECT_PUBLICATION_NAMESPACE) and user mappings (OBJECT_USER_MAPPING), pg_get_object_address() checked the array length of the second argument, but not of the first argument. If the first argument was too long, it would just silently ignore everything but the first argument. Fix that by checking the length of the first argument as well. Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/caaef70b-a874-1088-92ef-5ac38269c33b%40enterprisedb.com
* Improve some GUC description stringsAlvaro Herrera2022-09-21
| | | | | | | | | It is not our usual style to use "we" in messages. Also, remove some noise words. Backpatch to 15. Noted by Kyotaro Horiguchi. Discussion: https://postgr.es/m/20220914.111507.13049297635620898.horikyota.ntt@gmail.com
* Suppress variable-set-but-not-used warnings from clang 15.Tom Lane2022-09-20
| | | | | | | | | | | | | | | | | | | | | | | | clang 15+ will issue a set-but-not-used warning when the only use of a variable is in autoincrements (e.g., "foo++;"). That's perfectly sensible, but it detects a few more cases that we'd not noticed before. Silence the warnings with our usual methods, such as PG_USED_FOR_ASSERTS_ONLY, or in one case by actually removing a useless variable. One thing that we can't nicely get rid of is that with %pure-parser, Bison emits "yynerrs" as a local variable that falls foul of this warning. To silence those, I inserted "(void) yynerrs;" in the top-level productions of affected grammars. Per recently-established project policy, this is a candidate for back-patching into out-of-support branches: it suppresses annoying compiler warnings but changes no behavior. Hence, back-patch to 9.5, which is as far as these patches go without issues. (A preliminary check shows that the prior branches need some other set-but-not-used cleanups too, so I'll leave them for another day.) Discussion: https://postgr.es/m/514615.1663615243@sss.pgh.pa.us
* Disable autovacuum in MERGE test scriptAlvaro Herrera2022-09-20
| | | | | | | | Otherwise, it can fail given sufficient bad luck. Backpatch to 15. Discussion: https://postgr.es/m/537759.1663625579@sss.pgh.pa.us
* Fix incorrect variable types for origin IDs in decode.cMichael Paquier2022-09-20
| | | | | | | | These variables used XLogRecPtr instead of RepOriginId. Author: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoBm-vNyBSXGp4bmJGvhr=S-EGc5q1dtV70cFTcJvLhC=Q@mail.gmail.com Backpatch-through: 14
* Fix misleading comment for get_cheapest_group_keys_orderDavid Rowley2022-09-20
| | | | | | | | | | | | | | | | | The header comment for get_cheapest_group_keys_order() claimed that the output arguments were set to a newly allocated list which may be freed by the calling function, however, this was not always true as the function would simply leave these arguments untouched in some cases. This tripped me up when working on 1349d2790 as I mistakenly assumed I could perform a list_concat with the output parameters. That turned out bad due to list_concat modifying the original input lists. In passing, make it more clear that the number of distinct values is important to reduce tiebreaks during sorts. Also, explain what the n_preordered parameter means. Backpatch-through: 15, where get_cheapest_group_keys_order was introduced.
* Fix out-dated comment in preprocess_groupclause()David Rowley2022-09-20
| | | | | | | | The comment claimed we don't consider other orders of the GROUP BY clause, but this is no longer true as of db0d67db2. Discussion: https://postgr.es/m/CAApHDvq65=9Ro+hLX1i9ugWEiNDvHrBibAO7ARcTnf38_JE+UQ@mail.gmail.com Backpatch-through: 15, where db0d67db2 was introduced.
* Fix icu tests with C localePeter Eisentraut2022-09-19
| | | | | | | | Similar to 1e08576691bf1a25c0e28745e5e800c44f2a1c76, but for the icu test suite. Reported-by: Christoph Berg <myon@debian.org> Discussion: https://www.postgresql.org/message-id/YyWeU61YMFwjVdxE@msg.df7cb.de
* Future-proof the recursion inside ExecShutdownNode().Tom Lane2022-09-19
| | | | | | | | | | | | | | | | | | | | | | | The API contract for planstate_tree_walker() callbacks is that they take a PlanState pointer and a context pointer. Somebody figured they could save a couple lines of code by ignoring that, and passing ExecShutdownNode itself as the walker even though it has but one argument. Somewhat remarkably, we've gotten away with that so far. However, it seems clear that the upcoming C2x standard means to forbid such cases, and compilers that actively break such code likely won't be far behind. So spend the extra few lines of code to do it honestly with a separate walker function. In HEAD, we might as well go further and remove ExecShutdownNode's useless return value. I left that as-is in back branches though, to forestall complaints about ABI breakage. Back-patch, with the thought that this might become of practical importance before our stable branches are all out of service. It doesn't seem to be fixing any live bug on any currently known platform, however. Discussion: https://postgr.es/m/208054.1663534665@sss.pgh.pa.us
* Improve GUC description punctuationPeter Eisentraut2022-09-19
| | | | partial backpatch of 0b039e3a8489c08ec61b4d40382047c389af91ad
* Add missing serial commasPeter Eisentraut2022-09-19
|
* Make check_usermap() parameter names consistent.Peter Geoghegan2022-09-17
| | | | | | | | | | | The function has a bool argument named "case_insensitive", but that was spelled "case_sensitive" in the declaration. Make them consistent now to avoid confusion in the future. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Michael Paquiër <michael@paquier.xyz> Discussion: https://postgr.es/m/CAH2-WznJt9CMM9KJTMjJh_zbL5hD9oX44qdJ4aqZtjFi-zA3Tg@mail.gmail.com Backpatch: 10-
* Include c.h instead of postgres.h in src/port/*p{read,write}*.cAndres Freund2022-09-17
| | | | | | | | Frontend code shouldn't include postgres.h. Some files in src/port/ need to include postgres.h/postgres_fe.h, but these files don't. Discussion: https://postgr.es/m/20220915022626.5xx3ccgkzpkqw5mq@awork3.anarazel.de Backpatch: 12-, where 3fd2a7932ef introduced (some) of these files
* pgstat: Create memory contexts below TopMemoryContextAndres Freund2022-09-17
| | | | | | | | | | | | | | | So far they were created below CacheMemoryContext. However, that's not guaranteed to exist in all situations, leading to memory contexts created as top-level contexts. There isn't actually a good reason anymore to create them below CacheMemoryContext, so just creating them below TopMemoryContext seems the best approach. Reported-by: Reid Thompson <reid.thompson@crunchydata.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Author: "Drouvot, Bertrand" <bdrouvot@amazon.com> Discussion: https://postgr.es/m/b948b729-42fe-f88c-2f4a-0e65d84c049b@amazon.com Backpatch: 15-
* Message style improvementsPeter Eisentraut2022-09-17
|
* Fix race condition in stats.sql added in 5264add7847Andres Freund2022-09-16
| | | | | | | | | | | | | | | Very occasionally the stats test failed due to the number of sessions not being updated yet. Likely this requires that there is contention on the database's stats entry. Solve this by forcing pending stats to be flushed before fetching the stats. I verified that there are no other test failures after making pgstat_report_stat() only flush stats when force = true. Per message from Tom Lane and buildfarm member crake. Discussion: https://postgr.es/m/3428246.1663271992@sss.pgh.pa.us Backpatch: 15-, where 5264add7847 added the test
* Improve plpgsql's ability to handle arguments declared as RECORD.Tom Lane2022-09-16
| | | | | | | | | | | | | | | | | Treat arguments declared as RECORD as if that were a polymorphic type (which it is, sort of), in that we substitute the actual argument type while forming the function cache lookup key. This allows the specific composite type to be known in some cases where it was not before, at the cost of making a separate function cache entry for each named composite type that's passed to the function during a session. The particular symptom discussed in bug #17610 could be solved in other more-efficient ways, but only at the cost of considerable development work, and there are other cases where we'd still fail without this. Per bug #17610 from Martin Jurča. Back-patch to v11 where we first allowed plpgsql functions to be declared as taking type RECORD. Discussion: https://postgr.es/m/17610-fb1eef75bf6c2364@postgresql.org
* Message wording improvementsPeter Eisentraut2022-09-16
|
* Fix createdb tests for C localePeter Eisentraut2022-09-16
| | | | | | | | | If the createdb tests run under the C locale, the database cluster will be initialized with encoding SQL_ASCII. With the checks added in c7db01e325a530ec38ec7ba57cd3ed32e123e33c, this will cause several ICU-related tests to fail because SQL_ASCII is not supported by ICU. To work around that, use initdb option -E UTF8 for those tests to get past that check.
* Don't allow creation of database with ICU locale with unsupported encodingPeter Eisentraut2022-09-16
| | | | | | | | | | | | | Check in CREATE DATABASE and initdb that the selected encoding is supported by ICU. Before, they would pass but users would later get an error from the server when they tried to use the database. Also document that initdb sets the encoding to UTF8 by default if the ICU locale provider is chosen. Author: Marina Polyakova <m.polyakova@postgrespro.ru> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://www.postgresql.org/message-id/6dd6db0984d86a51b7255ba79f111971@postgrespro.ru
* Detect format-string mistakes in the libpq_pipeline test module.Tom Lane2022-09-15
| | | | | | | | | | | | | | I happened to notice that libpq_pipeline's private implementation of pg_fatal lacked any pg_attribute_printf decoration. Indeed, adding that turned up a mistake! We'd likely never have noticed because the error exits in this code are unlikely to get hit, but still, it's a bug. We're so used to having the compiler check this stuff for us that a printf-like function without pg_attribute_printf is a land mine. I wonder if there is a way to detect such omissions. Back-patch to v14 where this code came in.
* Reset InstallXLogFileSegmentActive after walreceiver self-initiated exit.Noah Misch2022-09-15
| | | | | | | | | | | | | After commit cc2c7d65fc27e877c9f407587b0b92d46cd6dd16 added this flag, failure to reset it caused assertion failures. In non-assert builds, it made the system fail to achieve the objectives listed in that commit; chiefly, we might emit a spurious log message. Back-patch to v15, where that commit first appeared. Bharath Rupireddy and Kyotaro Horiguchi. Reviewed by Dilip Kumar, Nathan Bossart and Michael Paquier. Reported by Dilip Kumar. Discussion: https://postgr.es/m/CAFiTN-sE3ry=ycMPVtC+Djw4Fd7gbUGVv_qqw6qfzp=JLvqT3g@mail.gmail.com
* Fix grammar in error messageJohn Naylor2022-09-15
| | | | | | | | | | While at it, make ellipses formatting consistent when describing SQL statements. Ekaterina Kiryanova and Alexander Lakhin Reviewed by myself and Álvaro Herrera Discussion: https://www.postgresql.org/message-id/eed5cec0-a542-53da-6a5e-7789c6ed9817%40postgrespro.ru Backpatch only the grammar fix to v15
* Fix outdated convert_saop_to_hashed_saop commentDavid Rowley2022-09-15
| | | | | | | | | | | In 29f45e299, we added support for optimizing the execution of NOT IN(values) by using a hash table instead of a linear search over the array. That commit neglected to update the header comment for convert_saop_to_hashed_saop() to mention this fact. Here we fix that. Author: James Coleman Discussion: https://postgr.es/m/CAAaqYe99NUpAPcxgchGstgM23fmiGjqQPot8627YgkBgNt=BfA@mail.gmail.com Backpatch-through: 15, where 29f45e299 was added.
* Small wording improvementsPeter Eisentraut2022-09-14
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 20:16:19 +0000