Merged
Conversation
On the CREATE POLICY page, the description of per-command policies stated that SELECT policies are applied when an INSERT has an ON CONFLICT DO NOTHING clause. However, that is only the case if it includes an arbiter clause, so clarify that. While at it, also clarify the comment in the regression tests that cover this. Author: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Viktor Holmberg <v@viktorh.net> Discussion: https://postgr.es/m/CAEZATCXGwMQ+x00YY9XYG46T0kCajH=21QaYL9Xatz0dLKii+g@mail.gmail.com Backpatch-through: 14
On the INSERT page, mention that SELECT privileges are also required for any columns mentioned in the arbiter clause, including those referred to by the constraint, and clarify that this applies to all forms of ON CONFLICT, not just ON CONFLICT DO UPDATE. Author: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Viktor Holmberg <v@viktorh.net> Discussion: https://postgr.es/m/CAEZATCXGwMQ+x00YY9XYG46T0kCajH=21QaYL9Xatz0dLKii+g@mail.gmail.com Backpatch-through: 14
The buildfarm occasionally shows a variant row order in the output of this UPDATE ... RETURNING, implying that the preceding INSERT dropped one of the rows into some free space within the table rather than appending them all at the end. It's not entirely clear why that happens some times and not other times, but we have established that it's affected by concurrent activity in other databases of the cluster. In any case, the behavior is not wrong; the test is at fault for presuming that a seqscan will give deterministic row ordering. Add an ORDER BY atop the update to stop the buildfarm noise. The buildfarm seems to have shown this only in v18 and master branches, but just in case the cause is older, back-patch to all supported branches. Discussion: https://postgr.es/m/3866274.1770743162@sss.pgh.pa.us Backpatch-through: 14
The pg_stat_activity view shows information for aux processes, but the pg_stat_get_backend_wait_event() and pg_stat_get_backend_wait_event_type() functions did not. To fix, call AuxiliaryPidGetProc(pid) if BackendPidGetProc(pid) returns NULL, like we do in pg_stat_get_activity(). In version 17 and above, it's a little silly to use those functions when we already have the ProcNumber at hand, but it was necessary before v17 because the backend ID was different from ProcNumber. I have other plans for wait_event_info on master, so it doesn't seem worth applying a different fix on different versions now. Reviewed-by: Sami Imseih <samimseih@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://www.postgresql.org/message-id/c0320e04-6e85-4c49-80c5-27cfb3a58108@iki.fi Backpatch-through: 14
If the variable's value is null, exec_stmt_return() missed filling in estate->rettype. This is a pretty old bug, but we'd managed not to notice because that value isn't consulted for a null result ... unless we have to cast it to a domain. That case led to a failure with "cache lookup failed for type 0". The correct way to assign the data type is known by exec_eval_datum. While we could copy-and-paste that logic, it seems like a better idea to just invoke exec_eval_datum, as the ROW case already does. Reported-by: Pavel Stehule <pavel.stehule@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAFj8pRBT_ahexDf-zT-cyH8bMR_qcySKM8D5nv5MvTWPiatYGA@mail.gmail.com Backpatch-through: 14
It's currently only used in the server, but it was placed in src/port with the idea that it might be useful in client programs too. However, it will currently fail to link if used in a client program, because CHECK_FOR_INTERRUPTS() is not usable in client programs. Fix that by wrapping it in "#ifndef FRONTEND". Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de> Discussion: https://www.postgresql.org/message-id/21cc7a48-99d9-4f69-9a3f-2c2de61ac8e5%40iki.fi Backpatch-through: 18
This log message was referring to conflicts, but it is about checksum failures. The log message improved in this commit should never show up, due to the fact that pgstat_prepare_report_checksum_failure() should always be called before pgstat_report_checksum_failures_in_db(), with a stats entry already created in the pgstats shared hash table. The three code paths able to report database-level checksum failures follow already this requirement. Oversight in b96d3c3. Author: Wang Peng <215722532@qq.com> Discussion: https://postgr.es/m/tencent_9B6CD6D9D34AE28CDEADEC6188DB3BA1FE07@qq.com Backpatch-through: 18
The prior order caused spurious Valgrind errors. They're spurious because the ereport(ERROR) non-local exit discards the pointer in question. pg_mblen_cstr() ordered the checks correctly, but these other two did not. Back-patch to v14, like commit 1e7fe06. Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/20260214053821.fa.noahmisch@microsoft.com Backpatch-through: 14
Commit 1e7fe06 changed pg_mbstrlen_with_len() to ereport(ERROR) if the input ends in an incomplete character. Most callers want that. text_substring() does not. It detoasts the most bytes it could possibly need to get the requested number of characters. For example, to extract up to 2 chars from UTF8, it needs to detoast 8 bytes. In a string of 3-byte UTF8 chars, 8 bytes spans 2 complete chars and 1 partial char. Fix this by replacing this pg_mbstrlen_with_len() call with a string traversal that differs by stopping upon finding as many chars as the substring could need. This also makes SUBSTRING() stop raising an encoding error if the incomplete char is past the end of the substring. This is consistent with the general philosophy of the above commit, which was to raise errors on a just-in-time basis. Before the above commit, SUBSTRING() never raised an encoding error. SUBSTRING() has long been detoasting enough for one more char than needed, because it did not distinguish exclusive and inclusive end position. For avoidance of doubt, stop detoasting extra. Back-patch to v14, like the above commit. For applications using SUBSTRING() on non-ASCII column values, consider applying this to your copy of any of the February 12, 2026 releases. Reported-by: SATŌ Kentarō <ranvis@gmail.com> Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Bug: #19406 Discussion: https://postgr.es/m/19406-9867fddddd724fca@postgresql.org Backpatch-through: 14
The error message added in 379695d referred to the public key being too long. This is confusing as it is in fact the session key included in a PGP message which is too long. This is harmless, but let's be precise about what is wrong. Per offline report. Reported-by: Zsolt Parragi <zsolt.parragi@percona.com> Backpatch-through: 14
'latest_page_number' is set to the correct value, according to nextOffset, early at system startup. Contrary to the comment, it hence should be set up correctly by the time we get to WAL replay. This fixes a failure to replay WAL generated on older minor versions, before commit 789d653 (18.2, 17.8, 16.12, 15.16, 14.21). The failure occurs after a truncation record has been replayed and looks like this: FATAL: could not access status of transaction 858112 DETAIL: Could not read from file "pg_multixact/offsets/000D" at offset 24576: read too few bytes. CONTEXT: WAL redo at 3/2A3AB408 for MultiXact/CREATE_ID: 858111 offset 6695072 nmembers 5: 1048228 (sh) 1048271 (keysh) 1048316 (sh) 1048344 (keysh) 1048370 (sh) Reported-by: Sebastian Webber <sebastian@swebber.me> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: Kirill Reshke <reshkekirill@gmail.com> Discussion: https://www.postgresql.org/message-id/20260214090150.GC2297@p46.dedyn.io;lightning.p46.dedyn.io Backpatch-through: 14-18
The receive function of hstore was not able to handle correctly duplicate key values when a new duplicate links to a NULL value, where a pfree() could be attempted on a NULL pointer, crashing due to a pointer dereference. This problem would happen for a COPY BINARY, when stacking values like that: aa => 5 aa => null The second key/value pair is discarded and pfree() calls are attempted on its key and its value, leading to a pointer dereference for the value part as the value is NULL. The first key/value pair takes priority when a duplicate is found. Per offline report. Reported-by: "Anemone" <vergissmeinnichtzh@gmail.com> Reported-by: "A1ex" <alex000young@gmail.com> Backpatch-through: 14
Various buildfarm members, having compilers like gcc 8.5 and 6.3, fail to deduce that text_substring() variable "E" is initialized if slice_size!=-1. This suppression approach quiets gcc 8.5; I did not reproduce the warning elsewhere. Back-patch to v14, like commit 9f4fd11. Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/1157953.1771266105@sss.pgh.pa.us Backpatch-through: 14
Commit c67bef3 introduced this test helper function for use by src/test/regress/sql/encoding.sql, but its logic was incorrect. It confused an encoding ID for a boolean so it gave the wrong results for some inputs, and also forgot the usual return macro. The mistake didn't affect values actually used in the test, so there is no change in behavior. Also drop it and another missed function at the end of the test, for consistency. Backpatch-through: 14 Author: Zsolt Parragi <zsolt.parragi@percona.com>
Commit 4603903 unfortunately reset the volatility of these functions to STABLE whereas they had previously been set to IMMUTABLE. We can't force a catalog update in the stable release, although a pg_update would probably do the trick. A simpler fix, though, for affected users is probably a simple catalog surgery along the lines of: UPDATE pg_proc SET provolatile = 'i' WHERE oid in (3261,3262); Applied to 18 only. In master we are planning to get rid of the separate redeclarations for defaults in system_functions.sql. Bug: #19409 Reported-By: Lucio Chiessi <lucio.chiessi@trustly.com> Discussion: https://postgr.es/m/19409-e16cd2605e59a4af@postgresql.org
table_tuple_update's update_indexes argument hasn't been a boolean since commit 19d8e23. Backpatch-through: 16
Otherwise the message is not very clear. Backpatch-through: 18
When adjust_appendrel_attrs translates a Var referencing a parent relation into a Var referencing a child relation, it propagates varnullingrels from the parent Var to the translated Var. Previously, the code simply overwrote the translated Var's varnullingrels with those of the parent. This was incorrect because the translated Var might already possess nonempty varnullingrels. This happens, for example, when a LATERAL subquery within a UNION ALL references a Var from the nullable side of an outer join. In such cases, the translated Var correctly carries the outer join's relid in its varnullingrels. Overwriting these bits with the parent Var's set caused the planner to lose track of the fact that the Var could be nulled by that outer join. In the reported case, because the underlying column had a NOT NULL constraint, the planner incorrectly deduced that the Var could never be NULL and discarded essential IS NOT NULL filters. This led to incorrect query results where NULL rows were returned instead of being filtered out. To fix, use bms_add_members to merge the parent Var's varnullingrels into the translated Var's existing set, preserving both sources of nullability. Back-patch to v16. Although the reported case does not seem to cause problems in v16, leaving incorrect varnullingrels in the tree seems like a trap for the unwary. Bug: #19412 Reported-by: Sergey Shinderuk <s.shinderuk@postgrespro.ru> Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19412-1d0318089b86859e@postgresql.org Backpatch-through: 16
If the 'bounds' array needs to be expanded, because the input contains more trigrams than the initial guess, the code didn't return the reallocated array correctly to the caller. That could lead to a crash in the rare case that the input string becomes longer when it's lower-cased. The only known instance of that is when an ICU locale is used with certain single-byte encodings. This was an oversight in commit 00896dd. Author: Zsolt Parragi <zsolt.parragi@percona.com> Backpatch-through: 18
As usual, the release notes for other branches will be made by cutting these down, but put them up for community review first.
If a CREATE TABLE statement defined a constraint whose name is identical to the name generated for a NOT NULL constraint, we'd throw an (unnecessary) unique key violation error on pg_constraint_conrelid_contypid_conname_index: this can easily be avoided by choosing a different name for the NOT NULL constraint. Fix by passing the constraint names already created by AddRelationNewConstraints() to AddRelationNotNullConstraints(), so that the latter can avoid name collisions with them. Bug: #19393 Author: Laurenz Albe <laurenz.albe@cybertec.at> Reported-by: Hüseyin Demir <huseyin.d3r@gmail.com> Backpatch-through: 18 Discussion: https://postgr.es/m/19393-6a82427485a744cf@postgresql.org
Commit 8d9a97e anticipated this change: 1 function with incompatible sub-type changes: [C] 'function List* AddRelationNotNullConstraints(Relation, List*, List*)' has some sub-type changes: parameter 4 of type 'List*' was added Discussion: https://postgr.es/m/19393-6a82427485a744cf@postgresql.org Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-02-21%2011%3A27%3A03 Backpatch-through: 18 only
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 8edd578f1856e2ac142bb3bb7090ec0a58cd8ac6
insert.sgmlの18.3対応です
Update for Release 18.3 (new pull request)
create_policy.sgmlの18.3対応です
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.