aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Convert node test compile-time settings into run-time parametersPeter Eisentraut2024-08-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This converts COPY_PARSE_PLAN_TREES WRITE_READ_PARSE_PLAN_TREES RAW_EXPRESSION_COVERAGE_TEST into run-time parameters debug_copy_parse_plan_trees debug_write_read_parse_plan_trees debug_raw_expression_coverage_test They can be activated for tests using PG_TEST_INITDB_EXTRA_OPTS. The compile-time symbols are kept for build farm compatibility, but they now just determine the default value of the run-time settings. Furthermore, support for these settings is not compiled in at all unless assertions are enabled, or the new symbol DEBUG_NODE_TESTS_ENABLED is defined at compile time, or any of the legacy compile-time setting symbols are defined. So there is no run-time overhead in production builds. (This is similar to the handling of DISCARD_CACHES_ENABLED.) Discussion: https://www.postgresql.org/message-id/flat/30747bd8-f51e-4e0c-a310-a6e2c37ec8aa%40eisentraut.org
* Avoid duplicate table scans for cross-partition updates during logical ↵Amit Kapila2024-08-01
| | | | | | | | | | | | | | replication. When performing a cross-partition update in the apply worker, it needlessly scans the old partition twice, resulting in noticeable overhead. This commit optimizes it by removing the redundant table scan. Author: Hou Zhijie Reviewed-by: Hayato Kuroda, Amit Kapila Discussion: https://postgr.es/m/OS0PR01MB571623E39984D94CBB5341D994AB2@OS0PR01MB5716.jpnprd01.prod.outlook.com
* Evaluate arguments of correlated SubPlans in the referencing ExprStateAndres Freund2024-07-31
| | | | | | | | | | | | | | | | | | | | | | | Until now we generated an ExprState for each parameter to a SubPlan and evaluated them one-by-one ExecScanSubPlan. That's sub-optimal as creating lots of small ExprStates a) makes JIT compilation more expensive b) wastes memory c) is a bit slower to execute This commit arranges to evaluate parameters to a SubPlan as part of the ExprState referencing a SubPlan, using the new EEOP_PARAM_SET expression step. We emit one EEOP_PARAM_SET for each argument to a subplan, just before the EEOP_SUBPLAN step. It likely is worth using EEOP_PARAM_SET in other places as well, e.g. for SubPlan outputs, nestloop parameters and - more ambitiously - to get rid of ExprContext->domainValue/caseValue/ecxt_agg*. But that's for later. Author: Andres Freund <andres@anarazel.de> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Alena Rybakina <lena.ribackina@yandex.ru> Discussion: https://postgr.es/m/20230225214401.346ancgjqc3zmvek@awork3.anarazel.de
* Revert "Allow parallel workers to cope with a newly-created session user ID."Tom Lane2024-07-31
| | | | | | | | | | | | | | | | This reverts commit f5f30c22ed69fb37b896c4d4546b2ab823c3fd61. Some buildfarm animals are failing with "cannot change "client_encoding" during a parallel operation". It looks like assign_client_encoding is unhappy at being asked to roll back a client_encoding setting after a parallel worker encounters a failure. There must be more to it though: why didn't I see this during local testing? In any case, it's clear that moving the RestoreGUCState() call is not as side-effect-free as I thought. Given that the bug f5f30c22e intended to fix has gone unreported for years, it's not something that's urgent to fix; I'm not willing to risk messing with it further with only days to our next release wrap.
* Add is_create parameter to RefreshMatviewByOid().Jeff Davis2024-07-31
| | | | | | | | | RefreshMatviewByOid is used for both REFRESH and CREATE MATERIALIZED VIEW. This flag is currently just used for handling internal error messages, but also aimed to improve code-readability. Author: Yugo Nagata Discussion: https://postgr.es/m/20240726122630.70e889f63a4d7e26f8549de8@sraoss.co.jp
* Remove unused ParamListInfo argument from ExecRefreshMatView.Jeff Davis2024-07-31
| | | | | Author: Yugo Nagata Discussion: https://postgr.es/m/20240726122630.70e889f63a4d7e26f8549de8@sraoss.co.jp
* Allow parallel workers to cope with a newly-created session user ID.Tom Lane2024-07-31
| | | | | | | | | | | | | | | | | | | | | | | | Parallel workers failed after a sequence like BEGIN; CREATE USER foo; SET SESSION AUTHORIZATION foo; because check_session_authorization could not see the uncommitted pg_authid row for "foo". This is because we ran RestoreGUCState() in a separate transaction using an ordinary just-created snapshot. The same disease afflicts any other GUC that requires catalog lookups and isn't forgiving about the lookups failing. To fix, postpone RestoreGUCState() into the worker's main transaction after we've set up a snapshot duplicating the leader's. This affects check_transaction_isolation and check_transaction_deferrable, which think they should only run during transaction start. Make them act like check_transaction_read_only, which already knows it should silently accept the value when InitializingParallelWorker. Per bug #18545 from Andrey Rachitskiy. Back-patch to all supported branches, because this has been wrong for awhile. Discussion: https://postgr.es/m/18545-feba138862f19aaa@postgresql.org
* Improve performance of dumpSequenceData().Nathan Bossart2024-07-31
| | | | | | | | | | | | | | | | | | | | | | | | | As one might guess, this function dumps the sequence data. It is called once per sequence, and each such call executes a query to retrieve the relevant data for a single sequence. This can cause pg_dump to take significantly longer, especially when there are many sequences. This commit improves the performance of this function by gathering all the sequence data with a single query at the beginning of pg_dump. This information is stored in a sorted array that dumpSequenceData() can bsearch() for what it needs. This follows a similar approach as previous commits that introduced sorted arrays for role information, pg_class information, and sequence metadata. As with those commits, this patch will cause pg_dump to use more memory, but that isn't expected to be too egregious. Note that we use the brand new function pg_sequence_read_tuple() in the query that gathers all sequence data, so we must continue to use the preexisting query-per-sequence approach for versions older than 18. Reviewed-by: Euler Taveira, Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20240503025140.GA1227404%40nathanxps13
* Introduce pg_sequence_read_tuple().Nathan Bossart2024-07-31
| | | | | | | | | | | | | | | | | | | | This new function returns the data for the given sequence, i.e., the values within the sequence tuple. Since this function is a substitute for SELECT from the sequence, the SELECT privilege is required on the sequence in question. It returns all NULLs for sequences for which we lack privileges, other sessions' temporary sequences, and unlogged sequences on standbys. This function is primarily intended for use by pg_dump in a follow-up commit that will use it to optimize dumpSequenceData(). Like pg_sequence_last_value(), which is a support function for the pg_sequences system view, pg_sequence_read_tuple() is left undocumented. Bumps catversion. Reviewed-by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20240503025140.GA1227404%40nathanxps13
* Improve performance of dumpSequence().Nathan Bossart2024-07-31
| | | | | | | | | | | | | | | | | | | | | | | | | | This function dumps the sequence definitions. It is called once per sequence, and each such call executes a query to retrieve the metadata for a single sequence. This can cause pg_dump to take significantly longer, especially when there are many sequences. This commit improves the performance of this function by gathering all the sequence metadata with a single query at the beginning of pg_dump. This information is stored in a sorted array that dumpSequence() can bsearch() for what it needs. This follows a similar approach as commits d5e8930f50 and 2329cad1b9, which introduced sorted arrays for role information and pg_class information, respectively. As with those commits, this patch will cause pg_dump to use more memory, but that isn't expected to be too egregious. Note that before version 10, the sequence metadata was stored in the sequence relation itself, which makes it difficult to gather all the sequence metadata with a single query. For those older versions, we continue to use the preexisting query-per-sequence approach. Reviewed-by: Euler Taveira Discussion: https://postgr.es/m/20240503025140.GA1227404%40nathanxps13
* Parse sequence type and integer metadata in dumpSequence().Nathan Bossart2024-07-31
| | | | | | | | | | | | | | | | This commit modifies dumpSequence() to parse all the sequence metadata into the appropriate types instead of carting around string pointers to the PGresult data. Besides allowing us to free the PGresult storage earlier in the function, this eliminates the need to compare min_value and max_value to their respective defaults as strings. This is preparatory work for a follow-up commit that will improve the performance of dumpSequence() in a similar manner to how commit 2329cad1b9 optimized binary_upgrade_set_pg_class_oids(). Reviewed-by: Euler Taveira Discussion: https://postgr.es/m/20240503025140.GA1227404%40nathanxps13
* Fix random failure in 021_twophase.Amit Kapila2024-07-31
| | | | | | | | | | | After disabling the subscription, the failed test was changing the two_phase option for the subscription. We can't change the two_phase option for a subscription till the corresponding apply worker is active. The check to ensure that the replication apply worker has exited was incorrect. Author: Vignesh C Discussion: https://postgr.es/m/CALDaNm3YY+bzj+JWJbY+DsUgJ2mPk8OR1ttjVX2cywKr4BUgxw@mail.gmail.com
* Relax check for return value from second call of pg_strnxfrm().Jeff Davis2024-07-30
| | | | | | | | | strxfrm() is not guaranteed to return the exact number of bytes needed to store the result; it may return a higher value. Discussion: https://postgr.es/m/32f85d88d1f64395abfe5a10dd97a62a4d3474ce.camel@j-davis.com Reviewed-by: Heikki Linnakangas Backpatch-through: 16
* Refactor getWeights to write to caller-supplied bufferHeikki Linnakangas2024-07-30
| | | | | | | This gets rid of the static result buffer. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/7f86e06a-98c5-4ce3-8ec9-3885c8de0358@iki.fi
* Replace static buf with a stack-allocated one in ReadControlFileHeikki Linnakangas2024-07-30
| | | | | | | It's only used very locally within the function. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/7f86e06a-98c5-4ce3-8ec9-3885c8de0358@iki.fi
* Replace static buf with palloc in str_time()Heikki Linnakangas2024-07-30
| | | | | | | | | | The function is used only once in the startup process, so the leak into current memory context is harmless. This is a tiny step in making the server thread-safe. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/7f86e06a-98c5-4ce3-8ec9-3885c8de0358@iki.fi
* Replace static bufs with a StringInfo in cash_words()Heikki Linnakangas2024-07-30
| | | | | | | | | | | For clarity. The code was correct, and the buffer was large enough, but string manipulation with no bounds checking is scary. This incurs an extra palloc+pfree to every call, but in quick performance testing, it doesn't seem to be significant. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/7f86e06a-98c5-4ce3-8ec9-3885c8de0358@iki.fi
* Remove leftover function declarationHeikki Linnakangas2024-07-30
| | | | | | Commit 9d9b9d46f3 removed the function (or rather, moved it to a different source file and renamed it to SendCancelRequest), but forgot the declaration in the header file.
* Preserve tz when converting to jsonb timestamptzAndrew Dunstan2024-07-30
| | | | | | | | | | | | | | This removes an inconsistency in the treatment of different datatypes by the jsonpath timestamp_tz() function. Conversions from data types that are not timestamp-aware, such as date and timestamp, are now treated consistently with conversion from those that are such as timestamptz. Author: David Wheeler Reviewed-by: Junwang Zhao and Jeevan Chalke Discussion: https://postgr.es/m/7DE080CE-6D8C-4794-9BD1-7D9699172FAB%40justatheory.com Backpatch to release 17.
* Remove useless member of BackendParameters.Thomas Munro2024-07-30
| | | | | | | | Oversight in e2562667, which stopped using SpinlockSemaArray but forgot to remove it from the array. Reported-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/310f4005-91d7-42b2-ac70-92624260dd28%40iki.fi
* Require memory barrier support.Thomas Munro2024-07-30
| | | | | | | | | | | | | | | | | | Previously we had a fallback implementation that made a harmless system call, based on the assumption that system calls must contain a memory barrier. That shouldn't be reached on any current system, and it seems highly likely that we can easily find out how to request explicit memory barriers, if we've already had to find out how to do atomics on a hypothetical new system. Removed comments and a function name referred to a spinlock used for fallback memory barriers, but that changed in 1b468a13, which left some misleading words behind in a few places. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Suggested-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/721bf39a-ed8a-44b0-8b8e-be3bd81db748%40technowledgy.de Discussion: https://postgr.es/m/3351991.1697728588%40sss.pgh.pa.us
* Require compiler barrier support.Thomas Munro2024-07-30
| | | | | | | | | | | | | | | Previously we had a fallback implementation of pg_compiler_barrier() that called an empty function across a translation unit boundary so the compiler couldn't see what it did. That shouldn't be needed on any current systems, and might not even work with a link time optimizer. Since we now require compiler-specific knowledge of how to implement atomics, we should also know how to implement compiler barriers on a hypothetical new system. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Suggested-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/721bf39a-ed8a-44b0-8b8e-be3bd81db748%40technowledgy.de Discussion: https://postgr.es/m/3351991.1697728588%40sss.pgh.pa.us
* Remove --disable-atomics, require 32 bit atomics.Thomas Munro2024-07-30
| | | | | | | | | | | | | | | | | Modern versions of all relevant architectures and tool chains have atomics support. Since edadeb07, there is no remaining reason to carry code that simulates atomic flags and uint32 imperfectly with spinlocks. 64 bit atomics are still emulated with spinlocks, if needed, for now. Any modern compiler capable of implementing C11 <stdatomic.h> must have the underlying operations we need, though we don't require C11 yet. We detect certain compilers and architectures, so hypothetical new systems might need adjustments here. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (concept, not the patch) Reviewed-by: Andres Freund <andres@anarazel.de> (concept, not the patch) Discussion: https://postgr.es/m/3351991.1697728588%40sss.pgh.pa.us
* Remove --disable-spinlocks.Thomas Munro2024-07-30
| | | | | | | | | | A later change will require atomic support, so it wouldn't make sense for a hypothetical new system not to be able to implement spinlocks. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (concept, not the patch) Reviewed-by: Andres Freund <andres@anarazel.de> (concept, not the patch) Discussion: https://postgr.es/m/3351991.1697728588%40sss.pgh.pa.us
* pg_createsubscriber: Remove obsolete commentPeter Eisentraut2024-07-30
| | | | | | | | This comment should have been removed by commit b9639138262. There is no replication slot check on the primary anymore. Author: Euler Taveira <euler@eulerto.com> Discussion: https://www.postgresql.org/message-id/697d692f-f9d3-41f6-9f0e-29a4fb18e544@app.fastmail.com
* Stabilize xid_wraparound testsAndrew Dunstan2024-07-30
| | | | | | | | | | | | The tests had a race condition if autovacuum was set to off. Instead we create all the tables we are interested in with autovacuum disabled, so they are only ever touched when in danger of wraparound. Discussion: https://postgr.es/m/3e2cbd24-f45e-4b2b-ba83-8149214f0a4d@dunslane.net Masahiko Sawada (slightly tweaked by me) Backpatch to release 17 where these tests were introduced.
* pg_createsubscriber: Fix an unpredictable recovery wait time.Amit Kapila2024-07-30
| | | | | | | | | | | | | | | | | The problem is that the tool is using the LSN returned by pg_create_logical_replication_slot() as recovery_target_lsn. This LSN is ahead of the current WAL position and the recovery waits until the publisher writes a WAL record to reach the target and ends the recovery. On idle systems, this wait time is unpredictable and could lead to failure in promoting the subscriber. To avoid that, insert a harmless WAL record. Reported-by: Alexander Lakhin and Tom Lane Diagnosed-by: Hayato Kuroda Author: Euler Taveira Reviewed-by: Hayato Kuroda, Amit Kapila Backpatch-through: 17 Discussion: https://postgr.es/m/2377319.1719766794%40sss.pgh.pa.us Discussion: https://postgr.es/m/CA+TgmoYcY+Wb67NAwaHT7MvxCSeV86oSc+va9hHKaasE42ukyw@mail.gmail.com
* Disallow setting MAX_PARTITION_BUFFERS to less than 2David Rowley2024-07-30
| | | | | | | | | | | | | | Add some comments to mention that this value must be at least 2 and also add a StaticAssertDecl to cause compilation failure if anyone tries to build with an invalid value. The multiInsertBuffers list must have at least two elements due to how the code in CopyMultiInsertInfoFlush() pushes the current ResultRelInfo's CopyMultiInsertBuffer to the end of the list. If the first element is also the last element, bad things will happen. Author: Zhang Mingli <avamingli@gmail.com> Discussion: https://postgr.es/m/CAApHDvpQ6t9ROcqbD-OgqR04Kfq4vQKw79Vo6r5j%2BciHwsSfkA%40mail.gmail.com
* Make collation not depend on setlocale().Jeff Davis2024-07-30
| | | | | | | | | | | | | | | | | Now that the result of pg_newlocale_from_collation() is always non-NULL, then we can move the collate_is_c and ctype_is_c flags into pg_locale_t. That simplifies the logic in lc_collate_is_c() and lc_ctype_is_c(), removing the dependence on setlocale(). This commit also eliminates the multi-stage initialization of the collation cache. As long as we have catalog access, then it's now safe to call pg_newlocale_from_collation() without checking lc_collate_is_c() first. Discussion: https://postgr.es/m/cfd9eb85-c52a-4ec9-a90e-a5e4de56e57d@eisentraut.org Reviewed-by: Peter Eisentraut, Andreas Karlsson
* Fix partitionwise join with partially-redundant join clausesRichard Guo2024-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To determine if the two relations being joined can use partitionwise join, we need to verify the existence of equi-join conditions involving pairs of matching partition keys for all partition keys. Currently we do that by looking through the join's restriction clauses. However, it has been discovered that this approach is insufficient, because there might be partition keys known equal by a specific EC, but they do not form a join clause because it happens that other members of the EC than the partition keys are constrained to become a join clause. To address this issue, in addition to examining the join's restriction clauses, we also check if any partition keys are known equal by ECs, by leveraging function exprs_known_equal(). To accomplish this, we enhance exprs_known_equal() to check equality per the semantics of the opfamily, if provided. It could be argued that exprs_known_equal() could be called O(N^2) times, where N is the number of partition key expressions, resulting in noticeable performance costs if there are a lot of partition key expressions. But I think this is not a problem. The number of a joinrel's partition key expressions would only be equal to the join degree, since each base relation within the join contributes only one partition key expression. That is to say, it does not scale with the number of partitions. A benchmark with a query involving 5-way joins of partitioned tables, each with 3 partition keys and 1000 partitions, shows that the planning time is not significantly affected by this patch (within the margin of error), particularly when compared to the impact caused by partitionwise join. Thanks to Tom Lane for the idea of leveraging exprs_known_equal() to check if partition keys are known equal by ECs. Author: Richard Guo, Tom Lane Reviewed-by: Tom Lane, Ashutosh Bapat, Robert Haas Discussion: https://postgr.es/m/CAN_9JTzo_2F5dKLqXVtDX5V6dwqB0Xk+ihstpKEt3a1LT6X78A@mail.gmail.com
* Refactor the checks for parameterized partial pathsRichard Guo2024-07-30
| | | | | | | | | | | | | | | | | | | | | Parameterized partial paths are not supported, and we have several checks in try_partial_xxx_path functions to enforce this. For a partial nestloop join path, we need to ensure that if the inner path is parameterized, the parameterization is fully satisfied by the proposed outer path. For a partial merge/hashjoin join path, we need to ensure that the inner path is not parameterized. In all cases, we need to ensure that the outer path is not parameterized. However, the comment in try_partial_hashjoin_path does not describe this correctly. This patch fixes that. In addtion, this patch simplifies the checks peformed in try_partial_hashjoin_path and try_partial_mergejoin_path with the help of macro PATH_REQ_OUTER, and also adds asserts that the outer path is not parameterized in try_partial_xxx_path functions. Author: Richard Guo Discussion: https://postgr.es/m/CAMbWs48mKJ6g_GnYNa7dnw04MHaMK-jnAEBrMVhTp2uUg3Ut4A@mail.gmail.com
* Short-circuit sort_inner_and_outer if there are no mergejoin clausesRichard Guo2024-07-30
| | | | | | | | | | | | | | | | | | | | | | | | In sort_inner_and_outer, we create mergejoin join paths by explicitly sorting both relations on each possible ordering of the available mergejoin clauses. However, if there are no available mergejoin clauses, we can skip this process entirely. This patch introduces a check for mergeclause_list at the beginning of sort_inner_and_outer and exits the function if it is found to be empty. This might help skip all the statements that come before the call to select_outer_pathkeys_for_merge, including the build of UniquePaths in the case of JOIN_UNIQUE_OUTER or JOIN_UNIQUE_INNER. I doubt there's any measurable performance improvement, but throughout the run of the regression tests, sort_inner_and_outer is called a total of 44,424 times. Among these calls, there are 11,064 instances where mergeclause_list is found to be empty, which accounts for approximately one-fourth. I think this suggests that implementing this shortcut is worthwhile. Author: Richard Guo Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/CAMbWs48RKiZGFEd5A0JtztRY5ZdvVvNiHh0AKeuoz21F+0dVjQ@mail.gmail.com
* Add more debugging information when failing to read pgstats filesMichael Paquier2024-07-30
| | | | | | | | | | This is useful to know which part of a stats file is corrupted when reading it, adding to the server logs a WARNING with details about what could not be read before giving up with the remaining data in the file. Author: Michael Paquier Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/Zp8o6_cl0KSgsnvS@paquier.xyz
* SQL/JSON: Fix casting for integer EXISTS columns in JSON_TABLEAmit Langote2024-07-30
| | | | | | | | | | | | | | | | | | | | | | | | The current method of coercing the boolean result value of JsonPathExists() to the target type specified for an EXISTS column, which is to call the type's input function via json_populate_type(), leads to an error when the target type is integer, because the integer input function doesn't recognize boolean literal values as valid. Instead use the boolean-to-integer cast function for coercion in that case so that using integer or domains thereof as type for EXISTS columns works. Note that coercion for ON ERROR values TRUE and FALSE already works like that because the parser creates a cast expression including the cast function, but the coercion of the actual result value is not handled by the parser. Tests by Jian He. Reported-by: Jian He <jian.universality@gmail.com> Author: Jian He <jian.universality@gmail.com> Author: Amit Langote <amitlangote09@gmail.com> Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com Backpatch-through: 17
* SQL/JSON: Some fixes to JsonBehavior expression castingAmit Langote2024-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Remove the special case handling when casting the JsonBehavior expressions to types with typmod, like 86d33987 did for the casting of SQL/JSON constructor functions. 2. Fix casting for fixed-length character and bit string types by using assignment-level casts. This is again similar to what 86d33987 did, but for ON ERROR / EMPTY expressions. 3. Use runtime coercion for the boolean ON ERROR constants so that using fixed-length character string types, for example, for an EXISTS column doesn't cause a "value too long for type character(n)" when the parser tries to coerce the default ON ERROR value "false" to that type, that is, even when clause is not specified. 4. Simplify the conditions of when to use runtime coercion vs creating the cast expression in the parser itself. jsonb-valued expressions are now always coerced at runtime and boolean expressions too if the target type is a string type for the reasons mentioned above. Tests are taken from a patch that Jian He posted. Reported-by: Jian He <jian.universality@gmail.com> Author: Jian He <jian.universality@gmail.com> Author: Amit Langote <amitlangote09@gmail.com> Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com Backpatch-through: 17
* Do not return NULL from pg_newlocale_from_collation().Jeff Davis2024-07-29
| | | | | | | | | | | | | | | | | | | | Previously, pg_newlocale_from_collation() returned NULL as a special case for the DEFAULT_COLLATION_OID if the provider was libc. In that case the behavior would depend on the last call to setlocale(). Now, consistent with the other providers, it will return a pointer to default_locale, which is not dependent on setlocale(). Note: for the C and POSIX locales, the locale_t structure within the pg_locale_t will still be zero, because those locales are implemented with internal logic and do not use libc at all. lc_collate_is_c() and lc_ctype_is_c() still depend on setlocale() to determine the current locale, which will be removed in a subsequent commit. Discussion: https://postgr.es/m/cfd9eb85-c52a-4ec9-a90e-a5e4de56e57d@eisentraut.org Reviewed-by: Peter Eisentraut, Andreas Karlsson
* Detach syslogger from shared memoryHeikki Linnakangas2024-07-29
| | | | | | | | | | Commit aafc05de1b removed the calls to detach from shared memory from syslogger startup. That was not intentional, so put them back. Author: Rui Zhao Reviewed-by: Aleksander Alekseev Backpatch-through: 17 Discussion: https://www.postgresql.org/message-id/11505016-8cf3-4691-b996-7faed99b7877.xiyuan.zr@alibaba-inc.com
* Remove dead generators for cyrillic encoding conversion tablesHeikki Linnakangas2024-07-29
| | | | | | | | | | | | | | | | | | | | These tools were used to read the koi-iso.tab, koi-win.tab, and koi-alt.tab files, which contained the mappings between the single-byte cyrillic encodings. However, those data files were removed in commit 4c3c8c048d, back in 2003. These code generators have been unused and unusable ever since. The generated tables live in cyrillic_and_mic.c. There has been one change to the tables since they were generated in 1999, in commit f4b7624eb07a. So if we resurrected the original data tables, that change would need to be taken into account. So this code is very dead. The tables in cyrillic_and_mic.c, which were originally generated by these tools, are now the authoritative source for these mappings. Reviewed-by: Tom Lane, Aleksander Alekseev Discussion: https://www.postgresql.org/message-id/flat/a821c3dc-36ec-4cee-8b41-7ccaa17adb18@iki.fi
* Remove tab completion for CREATE UNLOGGED MATERIALIZED VIEW.Nathan Bossart2024-07-29
| | | | | | | | | | | | | | | | Commit 3bf3ab8c56 added support for unlogged materialized views, but commit 3223b25ff7 reverted that feature before it made it into a release. However, the latter commit left the grammar and tab-completion support intact. This commit removes the tab-completion support to prevent psql from recommending bogus commands. I've opted to keep the grammar support so that the server continues to emit a descriptive error when users try to create unlogged matviews. Reported-by: Daniel Westermann, px shi Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/ZR0P278MB092093E92263DE16734208A5D2C59%40ZR0P278MB0920.CHEP278.PROD.OUTLOOK.COM Discussion: https://postgr.es/m/CAAccyY%2BWg1Z-9tNfSwLmuZVgGOwqU5u1OP-RWcoAr2UZGuvN_w%40mail.gmail.com
* Count individual SQL commands in pg_restore's --transaction-size mode.Tom Lane2024-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The initial implementation in commit 959b38d77 counted one action per TOC entry (except for some special cases for multi-blob BLOBS entries). This assumes that TOC entries are all about equally complex, but it turns out that that assumption doesn't hold up very well in binary-upgrade mode. For example, even after the previous commit I was able to cause backend bloat with tables having many inherited constraints. There may be other cases too. (Since no serious problems have been reported with --single-transaction mode, we can conclude that the backend copes well with psql's regular restore scripts; but before 959b38d77 we never ran binary-upgrade restores with multi-command transactions.) To fix, count multi-command TOC entries as N actions, allowing the transaction size to be scaled down when we hit a complex TOC entry. Rather than add a SQL parser to pg_restore, approximate "multi command" by counting semicolons in the TOC entry's defn string. This will be fooled by semicolons appearing in string literals --- but the error is in the conservative direction, so it doesn't seem worth working harder. The biggest risk is with function/procedure TOC entries, but we can just explicitly skip those. (This is undoubtedly a hack, and maybe someday we'll be able to revert it after fixing the backend's bloat issues or rethinking what pg_dump emits in binary upgrade mode. But that surely isn't a project for v17.) Thanks to Alexander Korotkov for the let's-count-semicolons idea. Per report from Justin Pryzby. Back-patch to v17 where txn_size mode was introduced. Discussion: https://postgr.es/m/ZqEND4ZcTDBmcv31@pryzbyj2023
* Reduce number of commands dumpTableSchema emits for binary upgrade.Tom Lane2024-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid issuing a separate SQL UPDATE command for each column when directly manipulating pg_attribute contents in binary upgrade mode. With the separate updates, we triggered a relcache invalidation with each update. For a table with N columns, that causes O(N^2) relcache bloat in txn_size mode because the table's newly-created relcache entry can't be flushed till end of transaction. Reducing the number of commands should make it marginally faster as well as avoiding that problem. While at it, likewise avoid issuing a separate UPDATE on pg_constraint for each inherited constraint. This is less exciting, first because inherited (non-partitioned) constraints are relatively rare, and second because the backend has a good deal of trouble anyway with restoring tables containing many such constraints, due to MergeConstraintsIntoExisting being horribly inefficient. But it seems more consistent to do it this way here too, and it surely can't hurt. In passing, fix one place in dumpTableSchema that failed to use ONLY in ALTER TABLE. That's not a live bug, but it's inconsistent. Also avoid silently casting away const from string literals. Per report from Justin Pryzby. Back-patch to v17 where txn_size mode was introduced. Discussion: https://postgr.es/m/ZqEND4ZcTDBmcv31@pryzbyj2023
* Fix double-release of spinlockHeikki Linnakangas2024-07-29
| | | | | | | | | | | | | | | | Commit 9d9b9d46f3 added spinlocks to protect the fields in ProcSignal flags, but in EmitProcSignalBarrier(), the spinlock was released twice. With most spinlock implementations, releasing a lock that's not held is not easy to notice, because most of the time it does nothing, but if the spinlock was concurrently acquired by another process, it could lead to more serious issues. Fortunately, with the --disable-spinlocks emulation implementation, it caused more visible failures. In the passing, fix a type in comment and add an assertion that the procNumber passed to SendProcSignal looks valid. Discussion: https://www.postgresql.org/message-id/b8ce284c-18a2-4a79-afd3-1991a2e7d246@iki.fi
* Fix compiler warning/error about typedef redefinitionsHeikki Linnakangas2024-07-29
| | | | | | Per buildfarm member 'sifaka': procsignal.c:87:3: error: redefinition of typedef 'ProcSignalHeader' is a C11 feature [-Werror,-Wtypedef-redefinition]
* Move cancel key generation to after forking the backendHeikki Linnakangas2024-07-29
| | | | | | | | | | | | | | | | | | | | | | Move responsibility of generating the cancel key to the backend process. The cancel key is now generated after forking, and the backend advertises it in the ProcSignal array. When a cancel request arrives, the backend handling it scans the ProcSignal array to find the target pid and cancel key. This is similar to how this previously worked in the EXEC_BACKEND case with the ShmemBackendArray, just reusing the ProcSignal array. One notable change is that we no longer generate cancellation keys for non-backend processes. We generated them before just to prevent a malicious user from canceling them; the keys for non-backend processes were never actually given to anyone. There is now an explicit flag indicating whether a process has a valid key or not. I wrote this originally in preparation for supporting longer cancel keys, but it's a nice cleanup on its own. Reviewed-by: Jelte Fennema-Nio Discussion: https://www.postgresql.org/message-id/508d0505-8b7a-4864-a681-e7e5edfe32aa@iki.fi
* Fix outdated comment in smgrtruncate()Heikki Linnakangas2024-07-29
| | | | | | | | Commit c5315f4f44 replaced smgr_fsm_nblocks and smgr_vm_nblocks with smgr_cached_nblocks, but forgot to update this comment. Author: Kirill Reshke Discussion: https://www.postgresql.org/message-id/CALdSSPh9VA6SDSVjrcmSPEYramf%2BrFisK7GqJo1dtRnD3vddmA@mail.gmail.com
* Reduce memory used by partitionwise joinsRichard Guo2024-07-29
| | | | | | | | | | | | | | | | | | | In try_partitionwise_join, we aim to break down the join between two partitioned relations into joins between matching partitions. To achieve this, we iterate through each pair of partitions from the two joining relations and create child-join relations for them. With potentially thousands of partitions, the local objects allocated in each iteration can accumulate significant memory usage. Therefore, we opt to eagerly free these local objects at the end of each iteration. In line with this approach, this patch frees the bitmap set that represents the relids of child-join relations at the end of each iteration. Additionally, it modifies build_child_join_rel() to reuse the AppendRelInfo structures generated within each iteration. Author: Ashutosh Bapat Reviewed-by: David Christensen, Richard Guo Discussion: https://postgr.es/m/CAExHW5s4EqY43oB=ne6B2=-xLgrs9ZGeTr1NXwkGFt2j-OmaQQ@mail.gmail.com
* Simplify create_merge_append_path for clarityRichard Guo2024-07-29
| | | | | | | | | | | | | | | We don't currently support parameterized MergeAppend paths: there's little use for an ordered path on the inside of a nestloop. Given this, we can simplify create_merge_append_path by directly setting param_info to NULL instead of calling get_appendrel_parampathinfo. We can also simplify the Assert for child paths a little bit. This change won't make any measurable difference in performance; it's just for clarity's sake. Author: Richard Guo Reviewed-by: Alena Rybakina, Paul A Jungwirth Discussion: https://postgr.es/m/CAMbWs4_n1bgH2nACMuGsXZct3KH6PBFS0tPdQsXdstRfyxTunQ@mail.gmail.com
* Refactor pg_set_regex_collation() for clarity.Jeff Davis2024-07-28
| | | | | Discussion: https://postgr.es/m/63409030-2746-462e-beac-759bd43032ce@proxel.se Reviewed-by: Andreas Karlsson
* Add missing pointer dereference in pg_backend_memory_contexts viewDavid Rowley2024-07-29
| | | | | | | | | | | | | | | 32d3ed816 moved the logic for setting the context's name and ident into a reusable function. I missed adding a pointer dereference after copying and pasting the code into that function. The ident parameter is a pointer to the ident variable in the calling function, so the dereference is required to correctly determine if the contents of that variable is NULL or not. In passing, adjust the if condition to include an == NULL to make it more clear that it's not checking for == '\0'. Reported-by: Tom Lane, Coverity Discussion: https://postgr.es/m/2256588.1722184287@sss.pgh.pa.us
* Fix whitespace in commit 005c6b833f.Jeff Davis2024-07-28
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 17:43:56 +0000