summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2022-10-03Revert "Optimize order of GROUP BY keys".Tom Lane
This reverts commit db0d67db2401eb6238ccc04c6407a4fd4f985832 and several follow-on fixes. The idea of making a cost-based choice of the order of the sorting columns is not fundamentally unsound, but it requires cost information and data statistics that we don't really have. For example, relying on procost to distinguish the relative costs of different sort comparators is pretty pointless so long as most such comparator functions are labeled with cost 1.0. Moreover, estimating the number of comparisons done by Quicksort requires more than just an estimate of the number of distinct values in the input: you also need some idea of the sizes of the larger groups, if you want an estimate that's good to better than a factor of three or so. That's data that's often unknown or not very reliable. Worse, to arrive at estimates of the number of calls made to the lower-order-column comparison functions, the code needs to make estimates of the numbers of distinct values of multiple columns, which are necessarily even less trustworthy than per-column stats. Even if all the inputs are perfectly reliable, the cost algorithm as-implemented cannot offer useful information about how to order sorting columns beyond the point at which the average group size is estimated to drop to 1. Close inspection of the code added by db0d67db2 shows that there are also multiple small bugs. These could have been fixed, but there's not much point if we don't trust the estimates to be accurate in-principle. Finally, the changes in cost_sort's behavior made for very large changes (often a factor of 2 or so) in the cost estimates for all sorting operations, not only those for multi-column GROUP BY. That naturally changes plan choices in many situations, and there's precious little evidence to show that the changes are for the better. Given the above doubts about whether the new estimates are really trustworthy, it's hard to summon much confidence that these changes are better on the average. Since we're hard up against the release deadline for v15, let's revert these changes for now. We can always try again later. Note: in v15, I left T_PathKeyInfo in place in nodes.h even though it's unreferenced. Removing it would be an ABI break, and it seems a bit late in the release cycle for that. Discussion: https://postgr.es/m/TYAPR01MB586665EB5FB2C3807E893941F5579@TYAPR01MB5866.jpnprd01.prod.outlook.com
2022-10-01doc: Fix some grammar and typosMichael Paquier
This fixes some areas related to logical replication and custom RMGRs. Author: Ekaterina Kiryanova Discussion: https://postgr.es/m/fa4773f1-1396-384a-bcd7-85b5e013f399@postgrespro.ru Backpatch-through: 15
2022-09-30Avoid improbable PANIC during heap_update, redux.Tom Lane
Commit 34f581c39 intended to ensure that RelationGetBufferForTuple would acquire a visibility-map page pin in case the otherBuffer's all-visible bit had become set since we last had lock on that page. But I missed a case: when we're extending the relation, VM concerns were dealt with only in the relatively-less-likely case that we fail to conditionally lock the otherBuffer. I think I'd believed that we couldn't need to worry about it if the conditional lock succeeds, which is true for the target buffer; but the otherBuffer was unlocked for awhile so its bit might be set anyway. So we need to do the GetVisibilityMapPins dance, and then also recheck the page's free space, in both cases. Per report from Jaime Casanova. Back-patch to v12 as the previous patch was (although there's still no evidence that the bug is reachable pre-v14). Discussion: https://postgr.es/m/E1lWLjP-00006Y-Ml@gemulon.postgresql.org
2022-09-30Fix tab-completion after commit 790bf615ddbaAlvaro Herrera
I (Álvaro) broke tab-completion for GRANT .. ALL TABLES IN SCHEMA while removing ALL from the publication syntax for schemas in the aforementioned commit. I also missed to update a bunch of tab-completion rules for ALTER/CREATE PUBLICATION that match each individual piece of ALL TABLES IN SCHEMA. Repair those bugs. While fixing up that commit, update a couple of outdated comments related to the same change. Backpatch to 15. Author: Shi yu <shiy.fnst@fujitsu.com> Reviewed-by: Peter Smith <smithpb2250@gmail.com> Discussion: https://postgr.es/m/OSZPR01MB6310FCE8609185A56344EED2FD559@OSZPR01MB6310.jpnprd01.prod.outlook.com
2022-09-29Fix bogus behavior of PQsslAttribute(conn, "library").Tom Lane
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
2022-09-29Update comment in ExecInsert() regarding batch insertion.Etsuro Fujita
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
2022-09-29Restrict Datum sort optimization to byval types onlyDavid Rowley
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.
2022-09-28Change some errdetail() to errdetail_internal()Alvaro Herrera
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.
2022-09-28Remove publicationcmds.c's expr_allowed_in_node as a functionAlvaro Herrera
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
2022-09-27Improve some publication-related error messagesAlvaro Herrera
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
2022-09-27Fix pg_stat_statements for MERGEAlvaro Herrera
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
2022-09-26ci: Add hint about downloadable logs to READMEAndres Freund
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
2022-09-26Translation updatesPeter Eisentraut
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 0a336c1e07ac371cf445a0cecac6b27720da228c
2022-09-25Fix tupdesc lifespan bug with AfterTriggersTableData.storeslot.Tom Lane
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
2022-09-25Avoid loss of code coverage with unlogged-index test cases.Tom Lane
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
2022-09-25Add missing source files to pg_waldump/nls.mkAlvaro Herrera
2022-09-24Message style improvementsPeter Eisentraut
2022-09-23Improve terminologyPeter Eisentraut
Use "prepared transaction" instead of "two-phrase transaction". This is in line with c5d67881d343a507269bde124a49df19e0296157.
2022-09-23pgstat: Fix transactional stats dropping for indexesAndres Freund
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
2022-09-23Remove PQsendQuery support in pipeline modeAlvaro Herrera
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
2022-09-23Stop using PQsendQuery in libpq_pipelineAlvaro Herrera
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
2022-09-23Allow publications with schema and table of the same schema.Amit Kapila
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
2022-09-22Fix race condition where heap_delete() fails to pin VM page.Jeff Davis
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
2022-09-22Remove ALL keyword from TABLES IN SCHEMA for publicationAlvaro Herrera
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
2022-09-22Use min/max bounds defined by Zstd for compression levelMichael Paquier
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
2022-09-22Fix thinko in comment.Etsuro Fujita
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
2022-09-22Clear ps display of startup process at the end of recoveryMichael Paquier
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
2022-09-22psql: Improve tab-completion for MERGE.Fujii Masao
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
2022-09-21Improve ICU option handling in CREATE DATABASEPeter Eisentraut
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
2022-09-21Tighten pg_get_object_address argument checkingPeter Eisentraut
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
2022-09-21Improve some GUC description stringsAlvaro Herrera
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
2022-09-20Suppress variable-set-but-not-used warnings from clang 15.Tom Lane
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
2022-09-20Disable autovacuum in MERGE test scriptAlvaro Herrera
Otherwise, it can fail given sufficient bad luck. Backpatch to 15. Discussion: https://postgr.es/m/537759.1663625579@sss.pgh.pa.us
2022-09-20Fix incorrect variable types for origin IDs in decode.cMichael Paquier
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
2022-09-20Fix misleading comment for get_cheapest_group_keys_orderDavid Rowley
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.
2022-09-20Fix out-dated comment in preprocess_groupclause()David Rowley
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.
2022-09-19Fix icu tests with C localePeter Eisentraut
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
2022-09-19Future-proof the recursion inside ExecShutdownNode().Tom Lane
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
2022-09-19Improve GUC description punctuationPeter Eisentraut
partial backpatch of 0b039e3a8489c08ec61b4d40382047c389af91ad
2022-09-19Add missing serial commasPeter Eisentraut
2022-09-17Make check_usermap() parameter names consistent.Peter Geoghegan
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-
2022-09-17Include c.h instead of postgres.h in src/port/*p{read,write}*.cAndres Freund
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
2022-09-17pgstat: Create memory contexts below TopMemoryContextAndres Freund
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-
2022-09-17Message style improvementsPeter Eisentraut
2022-09-16Fix race condition in stats.sql added in 5264add7847Andres Freund
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
2022-09-16Improve plpgsql's ability to handle arguments declared as RECORD.Tom Lane
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
2022-09-16Message wording improvementsPeter Eisentraut
2022-09-16Fix createdb tests for C localePeter Eisentraut
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.
2022-09-16Don't allow creation of database with ICU locale with unsupported encodingPeter Eisentraut
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
2022-09-15Detect format-string mistakes in the libpq_pipeline test module.Tom Lane
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.
generated by cgit v1.2.3 (git 2.46.0) at 2025-08-30 11:03:16 +0000