aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Make formatting in nls.mk files more consistentPeter Eisentraut2024-05-14
| | | | | | Some of the nls.mk files used different indentation or line breaks than the majority, which makes editing these files unnecessarily confusing.
* Revert "Temporarily install debugging in partition_prune test"David Rowley2024-05-14
| | | | | | | | | | | | 1db689715 added debugging output to the partition_prune regression test to help us figure out why buildfarm member Parula was occasionally failing. We've not seen any failures in around 4 weeks and the best guess as to what the problem was is a compiler bug. Since there are no recent failures, there's now no need to keep this debugging code, so revert it. Discussion: https://postgr.es/m/CAApHDvqyLF881EvDtXT=ossa0i4ioJBtW2c0Wbouzt5d3HDb5Q@mail.gmail.com
* Fix pg_sequence_last_value() for unlogged sequences on standbys.Nathan Bossart2024-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Presently, when this function is called for an unlogged sequence on a standby server, it will error out with a message like ERROR: could not open file "base/5/16388": No such file or directory Since the pg_sequences system view uses pg_sequence_last_value(), it can error similarly. To fix, modify the function to return NULL for unlogged sequences on standby servers. Since this bug is present on all versions since v15, this approach is preferable to making the ERROR nicer because we need to repair the pg_sequences view without modifying its definition on released versions. For consistency, this commit also modifies the function to return NULL for other sessions' temporary sequences. The pg_sequences view already appropriately filters out such sequences, so there's no bug there, but we might as well offer some defense in case someone invokes this function directly. Unlogged sequences were first introduced in v15, but temporary sequences are much older, so while the fix for unlogged sequences is only back-patched to v15, the temporary sequence portion is back-patched to all supported versions. We could also remove the privilege check in the pg_sequences view definition in v18 if we modify this function to return NULL for sequences for which the current user lacks privileges, but that is left as a future exercise for when v18 development begins. Reviewed-by: Tom Lane, Michael Paquier Discussion: https://postgr.es/m/20240501005730.GA594666%40nathanxps13 Backpatch-through: 12
* Remove COMMAND_TAG_NEXTTAG from enum CommandTag.Tom Lane2024-05-13
| | | | | | | | | | | COMMAND_TAG_NEXTTAG isn't really a valid command tag. Declaring it as if it were one prompts complaints from Coverity and perhaps other static analyzers. Our only use of it is in an entirely-unnecessary array sizing declaration, so let's just drop it. Ranier Vilela Discussion: https://postgr.es/m/CAEudQAoY0xrKuTAX7W10zsjjUpKBPFRtdCyScb3Z0FB2v6HNmQ@mail.gmail.com
* Fix regression tests conflict in 3ca43dbbb6Alexander Korotkov2024-05-13
| | | | | | | | | | | | | | | | 3ca43dbbb6 adds regression tests with permission checks. The conflict has been observed at buildfarm member piculet. This commit fixes the conflict in the following way. 1. partition_split.sql now uses role names regress_partition_split_alice and regress_partition_split_bob (it mistakenly used regress_partition_merge_alice and regress_partition_merge_bob before). 2. Permissions on schemas partitions_merge_schema and partition_split_schema are granted to corresponding roles. Before, the lack of permissions led to the creation of objects in the public schema and potential conflict. Reported-by: Daniel Gustafsson Discussion: https://postgr.es/m/03A07EF6-98D2-419B-A3AA-A111C64CC207%40yesql.se
* Revert structural changes to not-null constraintsAlvaro Herrera2024-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | There are some problems with the new way to handle these constraints that were detected at the last minute, and require fixes that appear too invasive to be doing this late in the cycle. Revert this (again) for now, we'll try again with these problems fixed. The following commits are reverted: b0e96f311985 Catalog not-null constraints 9b581c534186 Disallow changing NO INHERIT status of a not-null constraint d0ec2ddbe088 Fix not-null constraint test ac22a9545ca9 Move privilege check to the right place b0f7dd915bca Check stack depth in new recursive functions 3af721794272 Update information_schema definition for not-null constraints c3709100be73 Fix propagating attnotnull in multiple inheritance d9f686a72ee9 Fix restore of not-null constraints with inheritance d72d32f52d26 Don't try to assign smart names to constraints 0cd711271d42 Better handle indirect constraint drops 13daa33fa5a6 Disallow NO INHERIT not-null constraints on partitioned tables d45597f72fe5 Disallow direct change of NO INHERIT of not-null constraints 21ac38f498b3 Fix inconsistencies in error messages Discussion: https://postgr.es/m/202405110940.joxlqcx4dogd@alvherre.pgsql
* Fix test case to do what it intends toAlvaro Herrera2024-05-13
| | | | | | | | | | | | | This test case intended to fail because setting a column as generated to the partitioned table while leaving the partition alone is not allowed; but instead failed because of a discrepancy of not-null constraint. Fix this by adding the not-null constraint first, then set the column as generated in a separate ALTER TABLE command, which gets the expected error. Also, because the next test also wants to set the column as not-null, add a BEGIN/ROLLBACK block so that the added not-null is removed. Oversight in 699586315704.
* Add permission check for MERGE/SPLIT partition operationsAlexander Korotkov2024-05-13
| | | | | | | | | | | | Currently, we check only owner permission for the parent table before MERGE/SPLIT partition operations. This leads to a security hole when users can get access to the data of partitions without permission. This commit fixes this problem by requiring owner permission on all the partitions involved. Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/0520c72e-8d97-245e-53f9-173beca2ab2e%40gmail.com Author: Dmitry Koval, Alexander Korotkov
* injection_points: Store runtime conditions in private areaMichael Paquier2024-05-12
| | | | | | | | | | | | | | | | | | | | | | | This commit fixes a race condition between injection point run and detach, where a point detached by a backend and concurrently running in a second backend could cause the second backend to do an incorrect condition check. This issue happens because the second backend retrieves the callback information in a first step in the shmem hash table for injection points, and the condition in a second step within the callback. If the point is detached between these two steps, the condition would be removed, causing the point to run while it should not. Storing the condition in the new private_data area introduced in 33181b48fd0e ensures that the condition retrieved is consistent with its callback. This commit leads to a lot of simplifications in the module injection_points, as there is no need to handle the runtime conditions inside it anymore. Runtime conditions have no more a maximum number. Per discussion with Noah Misch. Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20240509031553.47@rfd.leadboat.com
* Introduce private data area for injection pointsMichael Paquier2024-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit extends the backend-side infrastructure of injection points so as it becomes possible to register some input data when attaching a point. This private data can be registered with the function name and the library name of the callback when attaching a point, then it is given as input argument to the callback. This gives the possibility for modules to pass down custom data at runtime when attaching a point without managing that internally, in a manner consistent with the callback entry retrieved from the hash shmem table storing the injection point data. InjectionPointAttach() gains two arguments, to be able to define the private data contents and its size. A follow-up commit will rely on this infrastructure to close a race condition with the injection point detach in the module injection_points. While on it, this changes InjectionPointDetach() to return a boolean, returning false if a point cannot be detached. This has been mentioned by Noah as useful when it comes to implement more complex tests with concurrent point detach, solid with the automatic detach done for local points in the test module. Documentation is adjusted in consequence. Per discussion with Noah Misch. Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20240509031553.47@rfd.leadboat.com
* Change ALPN protocol ID to IANA-approved "postgresql"Heikki Linnakangas2024-05-11
| | | | | | | | "TBD-pgsql" was a placeholder until the IANA registration was approved. Discussion: https://www.postgresql.org/message-id/87jzk2hj2n.fsf%40wibble.ilmari.org Discussion: https://mailarchive.ietf.org/arch/msg/tls-reg-review/9LWPzQfOpbc8dTT7vc9ahNeNaiw/
* Fix ON CONFLICT DO NOTHING/UPDATE for temporal indexesPeter Eisentraut2024-05-10
| | | | | | | | | | | | | | A PRIMARY KEY or UNIQUE constraint with WITHOUT OVERLAPS will be a GiST index, not a B-Tree, but it will still have indisunique set. The code for ON CONFLICT fails if it sees a non-btree index that has indisunique. This commit fixes that and adds some tests. But now that we can't just test indisunique, we also need some extra checks to prevent DO UPDATE from running against a WITHOUT OVERLAPS constraint (because the conflict could happen against more than one row, and we'd only update one). Author: Paul A. Jungwirth <pj@illuminatedcomputing.com> Discussion: https://www.postgresql.org/message-id/1426589a-83cb-4a89-bf40-713970c07e63@illuminatedcomputing.com
* Fix recursive RECORD-returning plpython functions.Tom Lane2024-05-09
| | | | | | | | | | | | | | | | | | | | If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54e19@proxel.se
* Repair ALTER EXTENSION ... SET SCHEMA.Tom Lane2024-05-09
| | | | | | | | | | | | | | | | | It turns out that we broke this in commit e5bc9454e, because the code was assuming that no dependent types would appear among the extension's direct dependencies, and now they do. This isn't terribly hard to fix: just skip dependent types, expecting that we will recurse to them when we process the parent object (which should also be among the direct dependencies). But a little bit of refactoring is needed so that we can avoid duplicating logic about what is a dependent type. Although there is some testing of ALTER EXTENSION SET SCHEMA, it failed to cover interesting cases, so add more tests. Discussion: https://postgr.es/m/930191.1715205151@sss.pgh.pa.us
* Make left-join removal safe under -DREALLOCATE_BITMAPSETS.Tom Lane2024-05-09
| | | | | | | | | | | | | | | | | | | | | | | | | The initial building of RestrictInfos and SpecialJoinInfos tends to create structures that share relid sets (such as syn_lefthand and outer_relids). There's nothing wrong with that in itself, but when we modify those relid sets during join removal, we have to be sure not to corrupt the values that other structures are pointing at. remove_rel_from_query() was careless about this. It accidentally worked anyway because (1) we'd never be reducing the sets to empty, so they wouldn't get pfree'd; and (2) the in-place modification is the same one that we did or will apply to the other struct's relid set, so that there wasn't visible corruption at the end of the process. While there's no live bug in a standard build, of course this is way too fragile to accept going forward. (Maybe we should back-patch this change too for safety, but I've refrained for now.) This bug was exposed by the recent invention of REALLOCATE_BITMAPSETS. Commit e0477837c had installed a fix, but that went away with the reversion of SJE, so now we need to fix it again. David Rowley and Tom Lane Discussion: https://postgr.es/m/CACJufxFVQmr4=JWHAOSLuKA5Zy9H26nY6tVrRFBOekHoALyCkQ@mail.gmail.com
* psql: Add missing punctuation in help outputPeter Eisentraut2024-05-09
|
* Fix inconsistencies in error messagesAlvaro Herrera2024-05-09
| | | | | | | | | | Reported by Kyotaro Horiguchi Also some comments mentioning wrong version numbers, spotted by Justin Pryzby. Discussion: https://postgr.es/m/20240507.171724.750916195320223609.horikyota.ntt@gmail.com Discussion: https://postgr.es/m/Zh0aAH7tbZb-9HbC@pryzbyj2023
* Fix overread in JSON parsing errors for incomplete byte sequencesMichael Paquier2024-05-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | json_lex_string() relies on pg_encoding_mblen_bounded() to point to the end of a JSON string when generating an error message, and the input it uses is not guaranteed to be null-terminated. It was possible to walk off the end of the input buffer by a few bytes when the last bytes consist of an incomplete multi-byte sequence, as token_terminator would point to a location defined by pg_encoding_mblen_bounded() rather than the end of the input. This commit switches token_terminator so as the error uses data up to the end of the JSON input. More work should be done so as this code could rely on an equivalent of report_invalid_encoding() so as incorrect byte sequences can show in error messages in a readable form. This requires work for at least two cases in the JSON parsing API: an incomplete token and an invalid escape sequence. A more complete solution may be too invasive for a backpatch, so this is left as a future improvement, taking care of the overread first. A test is added on HEAD as test_json_parser makes this issue straight-forward to check. Note that pg_encoding_mblen_bounded() no longer has any callers. This will be removed on HEAD with a separate commit, as this is proving to encourage unsafe coding. Author: Jacob Champion Discussion: https://postgr.es/m/CAOYmi+ncM7pwLS3AnKCSmoqqtpjvA8wmCdoBtKA3ZrB2hZG6zA@mail.gmail.com Backpatch-through: 13
* Add test for REPLICA IDENTITY with a temporal keyPeter Eisentraut2024-05-08
| | | | | | | | | You can only use REPLICA IDENTITY USING INDEX with a unique B-tree index. This commit just adds a test showing that you cannot use it with a WITHOUT OVERLAPS index (which is GiST). Author: Paul A. Jungwirth <pj@illuminatedcomputing.com> Discussion: https://www.postgresql.org/message-id/3775839b-3f0f-4c8a-ac03-a253222e6a4b%40illuminatedcomputing.com
* Fix typo in src/backend/utils/resowner/README.Etsuro Fujita2024-05-08
|
* Fix incorrect format placeholderPeter Eisentraut2024-05-08
|
* Ensure that "pg_restore -l" reports dependent TOC entries correctly.Tom Lane2024-05-07
| | | | | | | | | | | | | | If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because PrintTOCSummary neglected to update the te->reqs marking of the entry they depended on. Per report from Justin Pryzby. This has been wrong since 0d4e6ed30 taught _tocEntryRequired to sometimes look at the "reqs" marking of other TOC entries, so back-patch to all supported branches. Discussion: https://postgr.es/m/ZjoeirG7yxODdC4P@pryzbyj2023
* Don't corrupt plpython's "TD" dictionary in a recursive trigger call.Tom Lane2024-05-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853799@sss.pgh.pa.us
* Fix assorted bugs related to identity column in partitioned tablesPeter Eisentraut2024-05-07
| | | | | | | | | | | | | | | | | When changing the data type of a column of a partitioned table, craft the ALTER SEQUENCE command only once. Partitions do not have identity sequences of their own and thus do not need a ALTER SEQUENCE command for each partition. Fix getIdentitySequence() to fetch the identity sequence associated with the top-level partitioned table when a Relation of a partition is passed to it. While doing so, translate the attribute number of the partition into the attribute number of the partitioned table. Author: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> Reported-by: Alexander Lakhin <exclusion@gmail.com> Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com> Discussion: https://www.postgresql.org/message-id/3b8a9dc1-bbc7-0ef5-6863-c432afac7d59@gmail.com
* Remove obsolete comment.Jeff Davis2024-05-07
| | | | | | | | Per suggestion from Peter, the comment was not helpful, so remove it rather than fixing it. Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/d9421b21-e759-4b74-a039-c487b469c1f3@eisentraut.org
* Prevent RLS filters on ctid from breaking WHERE CURRENT OF <cursor>.Tom Lane2024-05-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | The executor only supports CurrentOfExpr as the sole tidqual of a TidScan plan node. tidpath.c failed to take any particular care about that, but would just take the first ctid equality qual it could find in the target relation's baserestrictinfo list. Originally that was fine because the grammar prevents any other WHERE conditions from being combined with CURRENT OF <cursor>. However, if the relation has RLS visibility policies then those would get included in the list. Should such a policy include a condition on ctid, we'd typically grab the wrong qual and produce a malfunctioning plan. To fix, introduce a simplistic priority ordering scheme for which ctid equality qual to prefer. Real-world cases involving more than one such qual are so rare that it doesn't seem worth going to any great trouble to choose one over another, so I didn't work very hard; but this code could be extended in future if someone thinks differently. It's extremely difficult to think of a reasonable use-case for an RLS restriction involving ctid, and certainly we've heard no field reports of this failure. So this doesn't seem worthy of back-patching, but in the name of cleanliness let's fix it going forward. Patch by me, per report from Robert Haas. Discussion: https://postgr.es/m/3914881.1715038270@sss.pgh.pa.us
* postgresql.conf: align variable comments, mostly new onesBruce Momjian2024-05-06
| | | | Backpatch-through: master
* Finish incomplete revert of ec63622c0.Tom Lane2024-05-06
| | | | | | | | | | The code change this made might well be fine to keep, but the comment justifying it by reference to self-join removal isn't. Let's just go back to the status quo ante, pending a more thorough review/redesign of SJE. (I found this by grepping to see if any references to self-join removal remained in the tree.)
* Fix privilege checks in pg_stats_ext and pg_stats_ext_exprs.Nathan Bossart2024-05-06
| | | | | | | | | | | | | | | | | | | | | | | The catalog view pg_stats_ext fails to consider privileges for expression statistics. The catalog view pg_stats_ext_exprs fails to consider privileges and row-level security policies. To fix, restrict the data in these views to table owners or roles that inherit privileges of the table owner. It may be possible to apply less restrictive privilege checks in some cases, but that is left as a future exercise. Furthermore, for pg_stats_ext_exprs, do not return data for tables with row-level security enabled, as is already done for pg_stats_ext. On the back-branches, a fix-CVE-2024-4317.sql script is provided that will install into the "share" directory. This file can be used to apply the fix to existing clusters. Bumps catversion on 'master' branch only. Reported-by: Lukas Fittl Reviewed-by: Noah Misch, Tomas Vondra, Tom Lane Security: CVE-2024-4317 Backpatch-through: 14
* Revert: Remove useless self-joinsAlexander Korotkov2024-05-06
| | | | | | | | | | | | | | | | | This commit reverts d3d55ce5713 and subsequent fixes 2b26a694554, 93c85db3b5b, b44a1708abe, b7f315c9d7d, 8a8ed916f73, b5fb6736ed3, 0a93f803f45, e0477837ce4, a7928a57b9f, 5ef34a8fc38, 30b4955a466, 8c441c08279, 028b15405b4, fe093994db4, 489072ab7a9, and 466979ef031. We are quite late in the release cycle and new bugs continue to appear. Even though we have fixes for all known bugs, there is a risk of throwing many bugs to end users. The plan for self-join elimination would be to do more review and testing, then re-commit in the early v18 cycle. Reported-by: Tom Lane Discussion: https://postgr.es/m/2422119.1714691974%40sss.pgh.pa.us
* Translation updatesPeter Eisentraut2024-05-06
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: be182cc55e6f72c66215fd9b38851969e3ce5480
* injection_points: Fix incorrect spinlock acquisitionMichael Paquier2024-05-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | Injection points created under injection_points_set_local() are cleaned up by a shmem_exit() callback. The spinlock used by the module would be hold while calling InjectionPointDetach(), which is incorrect as spinlocks should avoid external calls while hold. This commit changes the shmem_exit() callback to detach the points in three steps with the spinlock acquired twice, knowing that the injection points should be around with the conditions related to them: - Scans for the points to detach in a first loop, while holding the spinlock. - Detach them. - Remove the registered conditions. It is still possible for other processes to detach local points concurrently of the callback. I have wanted to restrict the detach, but Noah has mentioned that he has in mind some cases that may require this capability. No tests in the tree based on injection points need that currently. Thinko in f587338dec87. Reported-by: Noah Misch Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20240501231214.40@rfd.leadboat.com
* Silence Coverity complaint about possible null-pointer dereference.Tom Lane2024-05-05
| | | | | | | | | If pg_init_privs were to contain a NULL ACL field, this code would pass old_acl == NULL to merge_acl_with_grant, which would crash. The case shouldn't happen, but it just takes a couple more lines of code to guard against it, so do so. Oversight in 534287403; no back-patch needed.
* Fix comment regarding LibreSSL availabilityDaniel Gustafsson2024-05-05
| | | | | | | SSL_AD_NO_APPLICATION_PROTOCOL is indeed available in LibreSSL, but only in 3.4.3 and later (shipped in OpenBSD 7.0). Discussion: https://postgr.es/m/E1s1g0Z-000jeC-OR@gemulon.postgresql.org
* Fix query pullup issue with WindowClause runConditionDavid Rowley2024-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 94985c210 added code to detect when WindowFuncs were monotonic and allowed additional quals to be "pushed down" into the subquery to be used as WindowClause runConditions in order to short-circuit execution in nodeWindowAgg.c. The Node representation of runConditions wasn't well selected and because we do qual pushdown before planning the subquery, the planning of the subquery could perform subquery pull-up of nested subqueries. For WindowFuncs with args, the arguments could be changed after pushing the qual down to the subquery. This was made more difficult by the fact that the code duplicated the WindowFunc inside an OpExpr to include in the WindowClauses runCondition field. This could result in duplication of subqueries and a pull-up of such a subquery could result in another initplan parameter being issued for the 2nd version of the subplan. This could result in errors such as: ERROR: WindowFunc not found in subplan target lists To fix this, we change the node representation of these run conditions and instead of storing an OpExpr containing the WindowFunc in a list inside WindowClause, we now store a new node type named WindowFuncRunCondition within a new field in the WindowFunc. These get transformed into OpExprs later in planning once subquery pull-up has been performed. This problem did exist in v15 and v16, but that was fixed by 9d36b883b and e5d20bbd. Cat version bump due to new node type and modifying WindowFunc struct. Bug: #18305 Reported-by: Zuming Jiang Discussion: https://postgr.es/m/18305-33c49b4c830b37b3%40postgresql.org
* Fix an assortment of typosDavid Rowley2024-05-04
| | | | | Author: Alexander Lakhin Discussion: https://postgr.es/m/ae9f2fcb-4b24-5bb0-4240-efbbbd944ca1@gmail.com
* Fix expected test outputPeter Eisentraut2024-05-03
| | | | For builds without lz4, for 8f0a97dfff.
* Fix segmentation fault in MergeInheritedAttribute()Peter Eisentraut2024-05-03
| | | | | | | | | | | | | While converting a pg_attribute tuple into a ColumnDef, ColumnDef::compression remains NULL if there is no compression method set fot the attribute. Calling strcmp() with NULL ColumnDef::compression, when comparing compression methods of parents, causes segmentation fault in MergeInheritedAttribute(). Skip comparing compression methods if either of them is NULL. Author: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://www.postgresql.org/message-id/b22a6834-aacb-7b18-0424-a3f5fe889667%40gmail.com
* Throw a more on-point error for publications depending on columns.Tom Lane2024-05-02
| | | | | | | | | | Same as 42b041243, except that the trouble case is a publication WHERE clause that depends on a column. Again reported by Alexander Lakhin. Back-patch to v15 where we added publication WHERE clauses. Discussion: https://postgr.es/m/548a47bc-87ae-b3df-c6a2-60b9966f808b@gmail.com
* Disallow direct change of NO INHERIT of not-null constraintsAlvaro Herrera2024-05-02
| | | | | | | | | | | | | | | | | | | | | | | We support changing NO INHERIT constraint to INHERIT for constraints in child relations when adding a constraint to some ancestor relation, and also during pg_upgrade's schema restore; but other than those special cases, command ALTER TABLE ADD CONSTRAINT should not be allowed to change an existing constraint from NO INHERIT to INHERIT, as that would require to process child relations so that they also acquire an appropriate constraint, which we may not be in a position to do. (It'd also be surprising behavior.) It is conceivable that we want to allow ALTER TABLE SET NOT NULL to make such a change; but in that case some more code is needed to implement it correctly, so for now I've made that throw the same error message. Also, during the prep phase of ALTER TABLE ADD CONSTRAINT, acquire locks on all descendant tables; otherwise we might operate on child tables on which no locks are held, particularly in the mode where a primary key causes not-null constraints to be created on children. Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/7d923a66-55f0-3395-cd40-81c142b5448b@gmail.com
* Rename libpq trace internal functionsPeter Eisentraut2024-05-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libpq's pqTraceOutputMessage() used to look like this: case 'Z': /* Ready For Query */ pqTraceOutputZ(conn->Pfdebug, message, &logCursor); break; Commit f4b54e1ed98 introduced macros for protocol characters, so now it looks like this: case PqMsg_ReadyForQuery: pqTraceOutputZ(conn->Pfdebug, message, &logCursor); break; But this introduced a disconnect between the symbol in the switch case and the function name to be called, so this made the manageability of this file a bit worse. This patch changes the function names to match, so now it looks like this: case PqMsg_ReadyForQuery: pqTraceOutput_ReadyForQuery(conn->Pfdebug, message, &logCursor); break; (This also improves the readability of the file in general, since some function names like "pqTraceOutputt" were a little hard to read accurately.) Some protocol characters have different meanings to and from the server. The old code structure had a common function for both, for example, pqTraceOutputD(). The new structure splits this up into separate ones to match the protocol message name, like pqTraceOutput_Describe() and pqTraceOutput_DataRow(). Reviewed-by: Yugo NAGATA <nagata@sraoss.co.jp> Discussion: https://www.postgresql.org/message-id/flat/575e4f9d-acfe-45e3-b7f1-7e32c579090e%40eisentraut.org
* Disallow NO INHERIT not-null constraints on partitioned tablesAlvaro Herrera2024-05-02
| | | | | | | | | | | | | | | | Such constraints are semantically useless and only bring weird cases along, so reject them. As a side effect, we can no longer have "throwaway" constraints in pg_dump for primary keys in partitioned tables, but since they don't serve any useful purpose, we can just omit them. Maybe this should be done for all types of constraints, but it's just not-null ones that acquired this "ability" in the 17 timeframe, so for the moment I'm not changing anything else. Per note by Alexander Lakhin. Discussion: https://postgr.es/m/7d923a66-55f0-3395-cd40-81c142b5448b@gmail.com
* Skip invalid database pg_upgrade test on obsolete serversAlvaro Herrera2024-05-01
| | | | | | | | | | | | | | | | | | | | When testing pg_upgrade against an old server, ignore failures on the check to upgrade invalid databases. This is necessary because old servers don't know to raise the appropriate error of the database being invalid. This change causes no reduction in coverage, because such old versions don't know to mark databases invalid when a drop is interrupted; but testing against such old servers is useful in some circumstances. Backpatch to 16, where it cherry-picks with minimal conflicts. On 16, perltidy 20230309 chooses to change an unrelated line. I let it do that because that's the version we document as preferred for that branch, even though it would make other changes to many other files in the tree. Discussion: https://postgr.es/m/202404181539.lh42llaesnv3@alvherre.pgsql
* Fix typos and incorrect type in read_stream.cDavid Rowley2024-05-01
| | | | | | | | | max_ios should be int rather than int16, otherwise there's not much point in doing: max_ios = Min(max_ios, PG_INT16_MAX); Discussion: https://postgr.es/m/CAApHDvr9Un-XpDr_+AFdOGM38O2K8SpfoHimqZ838gguTGYBiQ@mail.gmail.com
* Fix parallel vacuum buffer usage reporting.Masahiko Sawada2024-05-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | A parallel worker's buffer usage is accumulated to its pgBufferUsage and then is accumulated into the leader's one at the end of the parallel vacuum. However, since the leader process used to use dedicated VacuumPage{Hit, Miss, Dirty} globals for the buffer usage reporting, the worker's buffer usage was not included, leading to an incorrect buffer usage report. To fix the problem, this commit makes vacuum use pgBufferUsage instruments for buffer usage reporting instead of VacuumPage{Hit, Miss, Dirty} globals. These global variables are still used by ANALYZE command and autoanalyze. This also fixes the buffer usage report of vacuuming on temporary tables, since the buffers dirtied by MarkLocalBufferDirty() were not tracked by the VacuumPageDirty variable. Parallel vacuum was introduced in 13, but the buffer usage reporting for VACUUM command with the VERBOSE option was implemented in 15. So backpatch to 15. Reported-by: Anthonin Bonnefoy Author: Anthonin Bonnefoy Reviewed-by: Alena Rybakina, Masahiko Sawada Discussion: https://postgr.es/m/CAO6_XqrQk+QZQcYs_C6nk0cMfHuUWk85vT9CrcA1NffFbAVE2A@mail.gmail.com Backpatch-through: 15
* Add tab completion for EXPLAIN (MEMORY|SERIALIZE)Michael Paquier2024-05-01
| | | | | | | SERIALIZE has been added in 06286709ee06, and MEMORY in 5de890e3610d. Author: Jian He Discussion: https://postgr.es/m/CACJufxH5UbhbCg-oMt7pHOmvNABF2x48Jfefu24FexSqVgzA3g@mail.gmail.com
* Ensure we allocate NAMEDATALEN bytes for names in Index Only ScansDavid Rowley2024-05-01
| | | | | | | | | | | | | | | As an optimization, we store "name" columns as cstrings in btree indexes. Here we modify it so that Index Only Scans convert these cstrings back to names with NAMEDATALEN bytes rather than storing the cstring in the tuple slot, as was happening previously. Bug: #17855 Reported-by: Alexander Lakhin Reviewed-by: Alexander Lakhin, Tom Lane Discussion: https://postgr.es/m/17855-5f523e0f9769a566@postgresql.org Backpatch-through: 12, all supported versions
* Fix locale options checking in CREATE DATABASE.Jeff Davis2024-04-30
| | | | | Discussion: https://postgr.es/m/4ea13583-7305-40b0-8525-58381533e2b1@eisentraut.org Reported-by: Peter Eisentraut
* Fix one more portability shortcoming in new test_pg_dump test.Tom Lane2024-04-30
| | | | | | | | | If the bootstrap superuser's name requires quoting, regroleout will supply double quotes ... but the result of CURRENT_USER is just the literal name. Apply quote_ident() to ensure a match. Per Andrew Dunstan's off-list investigation of buildfarm member prion's failures.
* Stabilize regression tests introduced by 259c96fa8fAlexander Korotkov2024-04-30
| | | | | | Add the ORDER BY clause to new queries to avoid ordering ambiguity. Per buildfarm member rorqual.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-22 01:40:57 +0000