aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Add BackendType for standalone backendsAndres Freund2022-08-22
| | | | | | | | | | | | | All backends should have a BackendType to enable statistics reporting per BackendType. Add a new BackendType for standalone backends, B_STANDALONE_BACKEND (and alphabetize the BackendTypes). Both the bootstrap backend and single user mode backends will have BackendType B_STANDALONE_BACKEND. Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/CAAKRu_aaq33UnG4TXq3S-OSXGWj1QGf0sU%2BECH4tNwGFNERkZA%40mail.gmail.com
* pgstat: Acquire lock when reading variable-numbered statsAndres Freund2022-08-22
| | | | | | | | | | | | | | Somewhere during the development of the patch acquiring a lock during read access to variable-numbered stats got lost. The missing lock acquisition won't cause corruption, but can lead to reading torn values when accessing stats. Add the missing lock acquisitions. Reported-by: Greg Stark <stark@mit.edu> Reviewed-by: "Drouvot, Bertrand" <bdrouvot@amazon.com> Reviewed-by: Andres Freund <andres@anarazel.de> Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/CAM-w4HMYkM_DkYhWtUGV+qE_rrBxKOzOF0+5faozxO3vXrc9wA@mail.gmail.com Backpatch: 15-
* Switch format specifier for replication origins to %dJohn Naylor2022-08-23
| | | | | | | | | Using %u with uint16 causes warnings with -Wformat-signedness. There are many other warnings, but for now change only these since c920fe4818 already changed the message string for most of them. Per report from Peter Eisentraut Discussion: https://www.postgresql.org/message-id/31e63649-0355-7088-831e-b07d5f908a8c%40enterprisedb.com
* Remove empty statementJohn Naylor2022-08-23
| | | | | | Peter Smith Discussion: https://www.postgresql.org/message-id/CAHut%2BPtRGVuj8Q_GpHHxZyk7fGwdYDG8_s4GSfKoc_4Yd9vR-w%40mail.gmail.com
* Make role grant system more consistent with other privileges.Robert Haas2022-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, membership of role A in role B could be recorded in the catalog tables only once. This meant that a new grant of role A to role B would overwrite the previous grant. For other object types, a new grant of permission on an object - in this case role A - exists along side the existing grant provided that the grantor is different. Either grant can be revoked independently of the other, and permissions remain so long as at least one grant remains. Make role grants work similarly. Previously, when granting membership in a role, the superuser could specify any role whatsoever as the grantor, but for other object types, the grantor of record must be either the owner of the object, or a role that currently has privileges to perform a similar GRANT. Implement the same scheme for role grants, treating the bootstrap superuser as the role owner since roles do not have owners. This means that attempting to revoke a grant, or admin option on a grant, can now fail if there are dependent privileges, and that CASCADE can be used to revoke these. It also means that you can't grant ADMIN OPTION on a role back to a user who granted it directly or indirectly to you, similar to how you can't give WITH GRANT OPTION on a privilege back to a role which granted it directly or indirectly to you. Previously, only the superuser could specify GRANTED BY with a user other than the current user. Relax that rule to allow the grantor to be any role whose privileges the current user posseses. This doesn't improve compatibility with what we do for other object types, where support for GRANTED BY is entirely vestigial, but it makes this feature more usable and seems to make sense to change at the same time we're changing related behaviors. Along the way, fix "ALTER GROUP group_name ADD USER user_name" to require the same privileges as "GRANT group_name TO user_name". Previously, CREATEROLE privileges were sufficient for either, but only the former form was permissible with ADMIN OPTION on the role. Now, either CREATEROLE or ADMIN OPTION on the role suffices for either spelling. Patch by me, reviewed by Stephen Frost. Discussion: http://postgr.es/m/CA+TgmoaFr-RZeQ+WoQ5nKPv97oT9+aDgK_a5+qWHSgbDsMp1Vg@mail.gmail.com
* Fix assertion failure in CREATE DATABASEPeter Eisentraut2022-08-22
| | | | | | | | | An assertion would fail when creating a database with libc locale provider from a template database with icu locale provider. Reported-by: Marina Polyakova <m.polyakova@postgrespro.ru> Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/f385ba25e7f8be427b8c582e5cca7d79%40postgrespro.ru#515a31c5429d6d37ad1d5c9d66962a1e
* pg_upgrade: Fix thinko in database info acquisition routinePeter Eisentraut2022-08-22
| | | | | | | | | | | When checking whether the major version supports per-database locale providers, it was always looking at the version of the old cluster instead of the cluster that was passed in. This would lead to failures to detect locale provider mismatches. Reported-by: Marina Polyakova <m.polyakova@postgrespro.ru> Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/f385ba25e7f8be427b8c582e5cca7d79%40postgrespro.ru#515a31c5429d6d37ad1d5c9d66962a1e
* Remove configure probes for sockaddr_storage members.Thomas Munro2022-08-22
| | | | | | | | | | | | | | | | | | | | | Remove four probes for members of sockaddr_storage. Keep only the probe for sockaddr's sa_len, which is enough for our two remaining places that know about _len fields: 1. ifaddr.c needs to know if sockaddr has sa_len to understand the result of ioctl(SIOCGIFCONF). Only AIX is still using the relevant code today, but it seems like a good idea to keep it compilable on Linux. 2. ip.c was testing for presence of ss_len to decide whether to fill in sun_len in our getaddrinfo_unix() function. It's just as good to test for sa_len. If you have one, you have them all. (The code in #2 isn't actually needed at all on several OSes I checked since modern versions ignore sa_len on input to system calls. Proving that's the case for all relevant OSes is left for another day, but wouldn't get rid of that last probe anyway if we still want it for #1.) Discussion: https://postgr.es/m/CA%2BhUKGJJjF2AqdU_Aug5n2MAc1gr%3DGykNjVBZq%2Bd6Jrcp3Dyvg%40mail.gmail.com
* Use logical operator && instead of & in vacuumparallel.c.Amit Kapila2022-08-22
| | | | | | | | | | | As such the current usage of & won't produce incorrect results but it would be better to use && to short-circuit the evaluation of second condition when the same is not required. Author: Ranier Vilela Reviewed-by: Tom Lane, Bharath Rupireddy Backpatch-through: 15, where it was introduced Discussion: https://postgr.es/m/CAEudQApL8QcoYwQuutkWKY_h7gBY8F0Xs34YKfc7-G0i83K_pw@mail.gmail.com
* Fix comment in walsender_private.hMichael Paquier2022-08-22
| | | | | | | | | All the members of the stucture are protected by the spinlock WalSnd, but a comment referred to "replyTime" and "latch" as not being in the set of what gets protected, contrary to what walsender.c does. Author: Bharath Rupireddy Discussion: https://postgr.es/m/CALj2ACWE_7srye4_GZ=N=-rD=qr2WHL9GZrMnhWJOJ5RdnNS2A@mail.gmail.com
* Remove dummyret definitionPeter Eisentraut2022-08-20
| | | | | | | | | This hasn't been used in a while (last use removed by 50d22de932, and before that 84b6d5f359), and since we are now preferring inline functions over complex macros, it's unlikely to be needed again. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://www.postgresql.org/message-id/flat/7110ab37-8ddd-437f-905c-6aa6205c6185%40enterprisedb.com
* regress: allow to specify directory containing expected files, for ecpgAndres Freund2022-08-20
| | | | | | | | | | | | | | | | | The ecpg tests have their input directory in the build directory, as the tests need to be built. Until now that required copying the expected/ directory to the build directory in VPATH builds. To avoid needing to implement the same for the meson build, add support for specifying the location of the expected directory. Now that that's not needed anymore, remove the copying of ecpg's expected directory to the build directory in VPATH builds. Author: Nazir Bilal Yavuz <byavuz81@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: https://postgr.es/m/20220718202327.pspcqz5mwbi2yb7w@awork3.anarazel.de
* Remove remaining mentions of UNSAFE_STAT_OKPeter Eisentraut2022-08-20
| | | | | | The last use was removed by bed90759fcbcd72d4d06969eebab81e47326f9a2. Discussion: https://www.postgresql.org/message-id/flat/01229f9a-b358-d71e-31ae-4c0855d73cbc%40enterprisedb.com
* Reduce warnings with -Wshadow=compatible-local buildsDavid Rowley2022-08-20
| | | | | | | | | In a similar effort to f01592f91, here we further reduce the warnings we get about local variables being shadowed when building with -Wshadow=compatible-local. This small change reduces the overall number of warnings by 36. Discussion: https://postgr.es/m/CAApHDvqBBqF=wmV5azrO7h3VwpwQo+JFBQ+g=E6wVUhKcqR8gA@mail.gmail.com
* Remove shadowed local variables that are new in v15David Rowley2022-08-20
| | | | | | | | | | | | | | | | | | | | | | | | | Compiling with -Wshadow=compatible-local yields quite a few warnings about local variables being shadowed by compatible local variables in an inner scope. Of course, this is perfectly valid in C, but we have had bugs in the past as a result of developers failing to notice this. af7d270dd is a recent example. Here we do a cleanup of warnings we receive from -Wshadow=compatible-local for code which is new to PostgreSQL 15. We've yet to have the discussion about if we actually ever want to run that as a standard compilation flag. We'll need to at least get the number of warnings down to something easier to manage before we can realistically consider if we want this or not. This commit is the first step towards reducing the warnings. The changes being made here are all fairly trivial. Because of that, and the fact that v15 is still in beta, this is being back-patched into 15. It seems more risky not to do this as the risk of future bugs is increased by the additional conflicts that this commit could cause for any future bug fixes touching the same areas as this commit. Author: Justin Pryzby Discussion: https://postgr.es/m/20220817145434.GC26426%40telsasoft.com Backpatch-through: 15
* Avoid reltuples distortion in very small tables.Peter Geoghegan2022-08-19
| | | | | | | | | | | | | | | | | | | | | | | Consistently avoid trusting a sample of only one page at the point that VACUUM determines a new reltuples for the target table (though only when the table is larger than a single page). This is follow-up work to commit 74388a1a, which added a heuristic to prevent reltuples from becoming distorted by successive VACUUM operations that each scan only a single heap page (which was itself more or less a bugfix for an issue in commit 44fa8488, which simplified VACUUM's handling of scanned pages). The original bugfix commit did not account for certain remaining cases that where not affected by its "2% of total relpages" heuristic. This happened with relations that are small enough that just one of its pages exceeded the 2% threshold, yet still big enough for VACUUM to deem skipping most of its pages via the visibility map worthwhile. reltuples could still become distorted over time with such a table, at least in scenarios where the VACUUM command is run repeatedly and without the table itself ever changing. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-Wzk7d4m3oEbEWkWQKd+gz-eD_peBvdXVk1a_KBygXadFeg@mail.gmail.com Backpatch: 15-, where the rules for scanned pages changed.
* Move a definition inside a header filePeter Eisentraut2022-08-19
| | | | | Over time, this has ended up in a slightly inappropriate place relative to the comments around it.
* Initialize index stats during parallel VACUUM.Peter Geoghegan2022-08-18
| | | | | | | | | | | | | Initialize shared memory allocated for index stats to avoid a hard crash. This was possible when parallel VACUUM became confused about the current phase of index processing. Oversight in commit 8e1fae1938, which refactored parallel VACUUM. Author: Masahiko Sawada <sawada.mshk@gmail.com> Reported-By: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20220818133406.GL26426@telsasoft.com Backpatch: 15-, the first version with the refactoring commit.
* Bump catversion for 6566133c5f52771198aca07ed18f84519fac1be7Robert Haas2022-08-18
| | | | Omission noted by Tom Lane.
* Don't add HAVE_LDAP_H HAVE_WINLDAP_H to pg_config.hAndres Freund2022-08-18
| | | | | | | They're not referenced, so we don't need them in in pg_config.h. Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: http://postgr.es/m/e0c44fb2-8b66-a4b9-b274-7ed3a1a0ab74@enterprisedb.com
* Ensure that pg_auth_members.grantor is always valid.Robert Haas2022-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, "GRANT foo TO bar" or "GRANT foo TO bar GRANTED BY baz" would record the OID of the grantor in pg_auth_members.grantor, but that role could later be dropped without modifying or removing the pg_auth_members record. That's not great, because we typically try to avoid dangling references in catalog data. Now, a role grant depends on the grantor, and the grantor can't be dropped without removing the grant or changing the grantor. "DROP OWNED BY" will remove the grant, just as it does for other kinds of privileges. "REASSIGN OWNED BY" will not, again just like what we do in other cases involving privileges. pg_auth_members now has an OID column, because that is needed in order for dependencies to work. It also now has an index on the grantor column, because otherwise dropping a role would require a sequential scan of the entire table to see whether the role's OID is in use as a grantor. That probably wouldn't be too large a problem in practice, but it seems better to have an index just in case. A follow-on patch is planned with the goal of more thoroughly rationalizing the behavior of role grants. This patch is just trying to do enough to make sure that the data we store in the catalogs is at some basic level valid. Patch by me, reviewed by Stephen Frost Discussion: http://postgr.es/m/CA+TgmoaFr-RZeQ+WoQ5nKPv97oT9+aDgK_a5+qWHSgbDsMp1Vg@mail.gmail.com
* Improve performance of adjust_appendrel_attrs_multilevel.Tom Lane2022-08-18
| | | | | | | | | | | | | | | | | | | | | | | | The present implementations of adjust_appendrel_attrs_multilevel and its sibling adjust_child_relids_multilevel are very messy, because they work by reconstructing the relids of the child's immediate parent and then seeing if that's bms_equal to the relids of the target parent. Aside from being quite inefficient, this will not work with planned future changes to make joinrels' relid sets contain outer-join relids in addition to baserels. The whole thing can be solved at a stroke by adding explicit parent and top_parent links to child RelOptInfos, and making these functions work with RelOptInfo pointers instead of relids. Doing that is simpler for most callers, too. In my original version of this patch, I got rid of RelOptInfo.top_parent_relids on the grounds that it was now redundant. However, that adds a lot of code churn in places that otherwise would not need changing, and arguably the extra indirection needed to fetch top_parent->relids in those places costs something. So this version leaves that field in place. Discussion: https://postgr.es/m/553080.1657481916@sss.pgh.pa.us
* Adjust assertion in XLogDecodeNextRecord.Robert Haas2022-08-18
| | | | | | | | | | | | | | | | | As written, if you use XLogBeginRead() to position an xlogreader at the beginning of a WAL page and then try to read WAL, this assertion will fail. However, the header comment for XLogBeginRead() claims that positioning an xlogreader at the beginning of a page is valid, and the code here is perfectly able to cope with it. It's only the assertion that causes trouble. So relax it. This is formally a bug in all supported branches, but as it doesn't seem to have any consequences for current uses of the xlogreader facility, no back-patch, at least for now. Dilip Kumar and Robert Haas Discussion: http://postgr.es/m/CA+TgmoaJSs2_7WHW2GzFYe9+zfPtxBKvT3GW47+x=ptUE=cULw@mail.gmail.com
* Fix subtly-incorrect matching of parent and child partitioned indexes.Tom Lane2022-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When creating a partitioned index, DefineIndex tries to identify any existing indexes on the partitions that match the partitioned index, so that it can absorb those as child indexes instead of building new ones. Part of the matching is to compare IndexInfo structs --- but that wasn't done quite right. We're comparing the IndexInfo built within DefineIndex itself to one made from existing catalog contents by BuildIndexInfo. Notably, while BuildIndexInfo will run index expressions and predicates through expression preprocessing, that has not happened to DefineIndex's struct. The result is failure to match and subsequent creation of duplicate indexes. The easiest and most bulletproof fix is to build a new IndexInfo using BuildIndexInfo, thereby guaranteeing that the processing done is identical. While here, let's also extract the opfamily and collation data from the new partitioned index, removing ad-hoc logic that duplicated knowledge about how those are constructed. Per report from Christophe Pettus. Back-patch to v11 where we invented partitioned indexes. Richard Guo and Tom Lane Discussion: https://postgr.es/m/8864BFAA-81FD-4BF9-8E06-7DEB8D4164ED@thebuild.com
* When using the WAL-logged CREATE DATABASE strategy, bulk extend.Robert Haas2022-08-18
| | | | | | | | | | This should improve performance, and was suggested by Andres Freund. Back-patch to v15 to keep the code consistent across branches. Dilip Kumar Discussion: http://postgr.es/m/C3458199-FEDD-4356-865A-08DFAA5D4065@anarazel.de Discussion: http://postgr.es/m/CAFiTN-sJ0vVpJrZ=R5M+g7Tr8=NN4wKOtrqOcDEsfFfnZgivVA@mail.gmail.com
* Remove unused configure variable.Tom Lane2022-08-18
| | | | | | | | | | configure extracts TCL_SHLIB_LD_LIBS from tclConfig.sh, and puts the value into Makefile.global, but then we never use it anywhere. It looks like I removed the only usage in cd75f94da, but didn't notice that it was the only usage. Might as well mop this up while we're trying to get rid of unnecessary configure steps. Discussion: https://postgr.es/m/2442359.1660835043@sss.pgh.pa.us
* Simplify and clarify an error messagePeter Eisentraut2022-08-18
|
* mstcpip.h is not missing on MinGW.Thomas Munro2022-08-18
| | | | | | | Remove a small difference between MinGW and MSVC builds which isn't needed for modern MinGW, noticed in passing. Discussion: https://postgr.es/m/CA+hUKGKErNfhmvb_H0UprEmp4LPzGN06yR2_0tYikjzB-2ECMw@mail.gmail.com
* Remove configure probe for netinet/tcp.h.Thomas Munro2022-08-18
| | | | | | | | <netinet/tcp.h> is in SUSv3 and all targeted Unix systems have it. For Windows, we can provide a stub include file, to avoid some #ifdef noise. Discussion: https://postgr.es/m/CA+hUKGKErNfhmvb_H0UprEmp4LPzGN06yR2_0tYikjzB-2ECMw@mail.gmail.com
* Fix macro problem with gai_strerror on Windows.Thomas Munro2022-08-18
| | | | | | | | | | Commit 5579388d was confused about why gai_strerror() didn't work, and used gai_strerrorA(). It turns out that we had explicitly undefined Windows' own macro for that somewhere else. Get rid of all that, and use the system headers' definition of gai_sterror() directly as intended. Discussion: https://postgr.es/m/CA+hUKGKErNfhmvb_H0UprEmp4LPzGN06yR2_0tYikjzB-2ECMw@mail.gmail.com
* Remove configure probe for sys/sockio.h.Thomas Munro2022-08-18
| | | | | | | | | | | On BSD-family systems, header <sys/sockio.h> defines socket ioctl numbers like SIOCGIFCONF. Only AIX is using those now, but it defines them in <net/if.h> anyway. Supposing some PostgreSQL hacker wants to test that AIX-only code path on a more common development system by pretending not to have getifaddrs(). It's enough to include <sys/ioctl.h>, at least on macOS, FreeBSD and Linux, and we're already doing that.
* Remove configure probe for net/if.h.Thomas Munro2022-08-18
| | | | | | | | | <net/if.h> is in SUSv3 and all targeted Unixes have it. It's used in a region that is already ifdef'd out for Windows. We're not using it for any standard definitions, but it's where AIX defines conventional socket ioctl numbers. Discussion: https://postgr.es/m/CA+hUKGKErNfhmvb_H0UprEmp4LPzGN06yR2_0tYikjzB-2ECMw@mail.gmail.com
* Remove dead ifaddr.c fallback code.Thomas Munro2022-08-18
| | | | | | | | | | | | | | | | | | | We carried a special implementation of pg_foreach_ifaddr() using Solaris's ioctl(SIOCGLIFCONF), but Solaris 11 and illumos adopted getifaddrs() more than a decade ago, and we prefer to use that. Solaris 10 is EOL'd. Remove the dead code. Adjust comment about which OSes have getifaddrs(), which also incorrectly listed AIX. AIX is in fact the only Unix in the build farm that *doesn't* have it today, so the implementation based on ioctl(SIOCGIFCONF) (note, no 'L') is still live. All the others have had it for at least one but mostly two decades. The last-stop fallback at the bottom of the file is dead code in practice, but it's hard to justify removing it because the better options are all non-standard. Discussion: https://postgr.es/m/CA+hUKGKErNfhmvb_H0UprEmp4LPzGN06yR2_0tYikjzB-2ECMw@mail.gmail.com
* Update comment in gramparse.hJohn Naylor2022-08-18
| | | | src/common/keywords.c hasn't included this header since afb0d0712.
* Refer to replication origin roident as "ID" in user facing messages and docsJohn Naylor2022-08-18
| | | | | | | | | | | | | | The table column that stores this is of type oid, but is actually limited to uint16 and has a different path for creating new values. Some of the documentation already referred to it as an ID, so let's standardize on that. While at it, most format strings already use %u, so for consintency change the remaining stragglers using %d. Per suggestions from Tom Lane and Justin Pryzby Discussion: https://www.postgresql.org/message-id/3437166.1659620465%40sss.pgh.pa.us Backpatch to v15
* Fix hypothetical problem passing the wrong GROUP BY pathkeysDavid Rowley2022-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1349d2790 changed things to make the planner request that the query_pathkeys contain pathkeys for any ORDER BY / DISTINCT aggregates. Some code added prior to that commit in db0d67db2 made it so the order that the pathkeys appear in the group_pathkeys could be changed so that the GROUP BY could be executed in a more optimal order which minimized sort comparisons. 1349d2790 had to make sure that the pathkeys for any ORDER BY / DISTINCT aggregates remained at the end of the groupby_pathkeys and wasn't reordered, so some code was added to add_paths_to_grouping_rel() to first strip off any pathkeys belonging to ORDER BY / DISTINCT aggregates before passing to the function to optimize the order of the group_pathkeys. It seems I dropped the ball in 1349d2790 and mistakenly used the untouched PlannerInfo.group_pathkeys to pass to get_useful_group_keys_orderings() instead of the version that had the aggregate pathkeys removed. It was only the code path that was handling creating paths for partially_grouped_rel which made this mistake. In practice, we'll never have any extra pathkeys to strip off when processing partially_grouped_rel as that's only used when considering partial paths, which we never do when there are ORDER BY / DISTINCT aggregates. So this is just a hypothetical bug, not a live bug. We already have the correct pathkeys determined, so it's of no extra cost to pass the correct variable. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20220817015755.GB26426@telsasoft.com
* Refactor addition of PlaceHolderVars to joinrel targetlists.Tom Lane2022-08-17
| | | | | | | | | | | | | | | | | | | Make build_joinrel_tlist() responsible for adding PHVs that were already computed in one or the other input relation, and therefore change add_placeholders_to_joinrel() to only add PHVs that will be newly computed in this joinrel's output. This makes the handling of PHVs in build_joinrel_tlist() more like its handling of plain Vars, which seems like a good thing on intelligibility grounds and will simplify planned future changes. There is a purely cosmetic side-effect that the order of entries in the joinrel's tlist may change; but since it becomes more like the order of entries in the input tlists, that's not bad. The reason it wasn't done like this originally was the potential cost of looking up PlaceHolderInfo entries to consult ph_needed. Now that that's O(1) it shouldn't hurt. Discussion: https://postgr.es/m/1405792.1660677844@sss.pgh.pa.us
* Use an explicit state flag to control PlaceHolderInfo creation.Tom Lane2022-08-17
| | | | | | | | | | | | | | | | | | | Up to now, callers of find_placeholder_info() were required to pass a flag indicating if it's OK to make a new PlaceHolderInfo. That'd be fine if the callers had free choice, but they do not. Once we begin deconstruct_jointree() it's no longer OK to make more PHIs; while callers before that always want to create a PHI if it's not there already. So there's no freedom of action, only the opportunity to cause bugs by creating PHIs too late. Let's get rid of that in favor of adding a state flag PlannerInfo.placeholdersFrozen, which we can set at the point where it's no longer OK to make more PHIs. This patch also simplifies a couple of call sites that were using complicated logic to avoid calling find_placeholder_info() as much as possible. Now that that lookup is O(1) thanks to the previous commit, the extra bitmap manipulations are probably a net negative. Discussion: https://postgr.es/m/1405792.1660677844@sss.pgh.pa.us
* Make PlaceHolderInfo lookup O(1).Tom Lane2022-08-17
| | | | | | | | | | | | | Up to now we've just searched the placeholder_list when we want to find the PlaceHolderInfo with a given ID. While there's no evidence of that being a problem in the field, an upcoming patch will add find_placeholder_info() calls in build_joinrel_tlist(), which seems likely to make it more of an issue: a joinrel emitting lots of PlaceHolderVars would incur O(N^2) cost, and we might be building a lot of joinrels in complex queries. Hence, add an array that can be indexed directly by phid to make the lookups constant-time. Discussion: https://postgr.es/m/1405792.1660677844@sss.pgh.pa.us
* Avoid using list_length() to test for empty list.Tom Lane2022-08-17
| | | | | | | | | | | | | | | | | | | | | | | | The standard way to check for list emptiness is to compare the List pointer to NIL; our list code goes out of its way to ensure that that is the only representation of an empty list. (An acceptable alternative is a plain boolean test for non-null pointer, but explicit mention of NIL is usually preferable.) Various places didn't get that memo and expressed the condition with list_length(), which might not be so bad except that there were such a variety of ways to check it exactly: equal to zero, less than or equal to zero, less than one, yadda yadda. In the name of code readability, let's standardize all those spellings as "list == NIL" or "list != NIL". (There's probably some microscopic efficiency gain too, though few of these look to be at all performance-critical.) A very small number of cases were left as-is because they seemed more consistent with other adjacent list_length tests that way. Peter Smith, with bikeshedding from a number of us Discussion: https://postgr.es/m/CAHut+PtQYe+ENX5KrONMfugf0q6NHg4hR5dAhqEXEc2eefFeig@mail.gmail.com
* Use SetInstallXLogFileSegmentActive() in more places in xlog.cMichael Paquier2022-08-17
| | | | | | | | | | This reduces the code paths where XLogCtl->InstallXLogFileSegmentActive is directly touched, and this wrapper function does the same thing as the original code replaced by the function call. Author: Bharath Rupireddy Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/CALj2ACVhkf-bC5CX-=6iBUfkO5GqmBntQH+m=HpY0iQ=-g1pRg@mail.gmail.com
* Allow event trigger table_rewrite for ALTER MATERIALIZED VIEWMichael Paquier2022-08-17
| | | | | | | | | | | This event can happen when using SET ACCESS METHOD, as the data files of the materialized need a full refresh but this command tag was not updated to reflect that. The documentation is updated to track this behavior. Author: Onder Kalaci Discussion: https://postgr.es/m/CACawEhXwHN3X34FiwoYG8vXR-oyUdrp7qcfRWSzS+NPahS5gSw@mail.gmail.com Backpatch-through: 15
* Fix assert in logicalmsg_descTomas Vondra2022-08-16
| | | | | | | | | | | The assert, introduced by 9f1cf97bb5, is intended to check if the prefix is terminated by a \0 byte, but it has two flaws. Firstly, prefix_size includes the \0 byte, so prefix[prefix_size] points to the byte after the null byte. Secondly, the check ensures the byte is not equal \0, while it should be checking the opposite. Backpatch-through: 14 Discussion: https://postgr.es/m/b99b6101-2f14-3796-3dfa-4a6cd7d4326d@enterprisedb.com
* Fix replica identity check for a partitioned table.Amit Kapila2022-08-16
| | | | | | | | | | | | | | The current publisher code checks if UPDATE or DELETE can be executed with the replica identity of the table even if it's a partitioned table. We can skip checking the replica identity for partitioned tables because the operations are actually performed on the leaf partitions (not the partitioned table). Reported-by: Brad Nicholson Author: Hou Zhijie Reviewed-by: Peter Smith, Amit Kapila Backpatch-through: 13 Discussion: https://postgr.es/m/CAMMnM%3D8i5DohH%3DYKzV0_wYuYSYvuOJoL9F5nzXTc%2ByzsG1f6rg%40mail.gmail.com
* Fix headerscheck and cpluspluscheck's exit codes.Thomas Munro2022-08-16
| | | | | | | | | | For the benefit of CI, which started running these header check scripts in its CompilerWarnings task in commit 81b9f23c9c8, they should report failure if any individual header failed to compile. Reviewed-by: Andrew Dunstan <andrew@dunslane.net> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA%2BhUKGKtDwPo9wzKgbStDwfOhEpywMc6PQofio8fAHR7yUjgxw%40mail.gmail.com
* Add missing bad-PGconn guards in libpq entry points.Tom Lane2022-08-15
| | | | | | | | | | | | | There's a convention that externally-visible libpq functions should check for a NULL PGconn pointer, and fail gracefully instead of crashing. PQflush() and PQisnonblocking() didn't get that memo though. Also add a similar check to PQdefaultSSLKeyPassHook_OpenSSL; while it's not clear that ordinary usage could reach that with a null conn pointer, it's cheap enough to check, so let's be consistent. Daniele Varrazzo and Tom Lane Discussion: https://postgr.es/m/CA+mi_8Zm_mVVyW1iNFgyMd9Oh0Nv8-F+7Y3-BqwMgTMHuo_h2Q@mail.gmail.com
* Remove redundant spaces in _outA_Expr() outputPeter Eisentraut2022-08-15
| | | | | | | | | Since WRITE_NODE_FIELD() output always starts with a space, we don't need to go out of our way to print another space right before it. This change is only for visual appearance; the tokenizer on the reading side would read it the same way (but there is no read support for A_Expr at this time anyway).
* Improve tab completion of ALTER TYPE in psqlMichael Paquier2022-08-15
| | | | | | | | | | This commit adds support for more tab completion in this command as of "ALTER TYPE .. SET". The completion of "RENAME VALUE" was separated from the rest of the completions done for this command, so group everything together. Author: Vignesh C Discussion: https://postgr.es/m/CALDaNm1u83jtD2wysdw9XwokEacSXEyUpELajEvOMgJTc3pQ7g@mail.gmail.com
* Fix outdated --help message for postgres -fMichael Paquier2022-08-15
| | | | | | | | | | This option switch supports a total of 8 values, as told by set_plan_disabling_options() and the documentation, but this was not reflected in the output generated by --help. Author: Junwang Zhao Discussion: https://postgr.es/m/CAEG8a3+pT3cWzyjzKs184L1XMNm8NDnoJLiSjAYSO7XqpRh_vA@mail.gmail.com Backpatch-through: 10
* Preserve memory context of VarStringSortSupport buffers.Tom Lane2022-08-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When enlarging the work buffers of a VarStringSortSupport object, varstrfastcmp_locale was careful to keep them in the ssup_cxt memory context; but varstr_abbrev_convert just used palloc(). The latter creates a hazard that the buffers could be freed out from under the VarStringSortSupport object, resulting in stomping on whatever gets allocated in that memory later. In practice, because we only use this code for ICU collations (cf. 3df9c374e), the problem is confined to use of ICU collations. I believe it may have been unreachable before the introduction of incremental sort, too, as traditional sorting usually just uses one context for the duration of the sort. We could fix this by making the broken stanzas in varstr_abbrev_convert match the non-broken ones in varstrfastcmp_locale. However, it seems like a better idea to dodge the issue altogether by replacing the pfree-and-allocate-anew coding with repalloc, which automatically preserves the chunk's memory context. This fix does add a few cycles because repalloc will copy the chunk's content, which the existing coding assumes is useless. However, we don't expect that these buffer enlargement operations are performance-critical. Besides that, it's far from obvious that copying the buffer contents isn't required, since these stanzas make no effort to mark the buffers invalid by resetting last_returned, cache_blob, etc. That seems to be safe upon examination, but it's fragile and could easily get broken in future, which wouldn't get revealed in testing with short-to-moderate-size strings. Per bug #17584 from James Inform. Whether or not the issue is reachable in the older branches, this code has been broken on its own terms from its introduction, so patch all the way back. Discussion: https://postgr.es/m/17584-95c79b4a7d771f44@postgresql.org
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-23 01:20:19 +0000