aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Add isolation tests for the combination of EPQ and triggers.Andres Freund2019-10-04
| | | | | | | | | | | | | | | | As evidenced by bug #16036 this area is woefully under-tested. Add fairly extensive tests for the combination. Backpatch back to 9.6 - before that isolationtester was not capable enough. While we don't backpatch tests all the time, future fixes to trigger.c would potentially look different enough in 12+ from the earlier branches that introducing bugs during backpatching is more likely than normal. Also, it's just a crucial and undertested area of the code. Author: Andres Freund Discussion: https://postgr.es/m/16036-28184c90d952fb7f@postgresql.org Backpatch: 9.6-, the earliest these tests work
* Fix crash caused by EPQ happening with a before update trigger present.Andres Freund2019-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When ExecBRUpdateTriggers()'s GetTupleForTrigger() follows an EPQ chain the former needs to run the result tuple through the junkfilter again, and update the slot containing the new version of the tuple to contain that new version. The input tuple may already be in the junkfilter's output slot, which used to be OK - we don't need the previous version anymore. Unfortunately ff11e7f4b9ae started to use ExecCopySlot() to update newslot, and ExecCopySlot() doesn't support copying a slot into itself, leading to a slot in a corrupt state, which then can cause crashes or other symptoms. Fix this by skipping the ExecCopySlot() when copying into itself. While we could have easily made ExecCopySlot() handle that case, it seems better to add an assert forbidding doing so instead. As the goal of copying might be to make the contents of one slot independent from another, it seems failure prone to handle doing so silently. A follow-up commit will add tests for the obviously under-covered combination of EPQ and triggers. Done as a separate commit as it might make sense to backpatch them further than this bug. Also remove confusion with confusing variable names for slots in ExecBRDeleteTriggers() and ExecBRUpdateTriggers(). Bug: #16036 Reported-By: Антон Власов Author: Andres Freund Discussion: https://postgr.es/m/16036-28184c90d952fb7f@postgresql.org Backpatch: 12-, where ff11e7f4b9ae was merged
* Use a fd opened for read/write when syncing slots during startup, take 2.Andres Freund2019-10-04
| | | | | | | | | | | | | | | | | | | | | | | Cribbing from dfbaed45975: Some operating systems, including the reporter's windows, return EBADFD or similar when fsync() is invoked on a O_RDONLY file descriptor. Unfortunately RestoreSlotFromDisk() does exactly that; which causes failures after restarts in at least some scenarios. If you hit the bug the error message will be something like ERROR: could not fsync file "pg_replslot/$name/state": Bad file descriptor Simply use O_RDWR instead of O_RDONLY when opening the relevant file descriptor to fix the bug. Unfortunately this fix was undone in 82a5649fb9db. Re-apply, and add a comment. Bug: 16039 Reported-By: Hans Buschmann Author: Andres Freund Discussion: https://postgr.es/m/16039-196fc97cc05e141c@postgresql.org Backpatch: 12-, as 82a5649fb9db
* Handle spaces in OpenSSL install location for MSVCAndrew Dunstan2019-10-04
| | | | | | | | | First, make sure that the .exe name is quoted when trying to get the version number. Also, don't quote the lib name for using in the project files if it's already been quoted. This second change applies to all libraries, not just OpenSSL. This has clearly been broken forever, so backpatch to all live branches.
* Fix bitshiftright()'s zero-padding some more.Tom Lane2019-10-04
| | | | | | | | | | | | | | | Commit 5ac0d9360 failed to entirely fix bitshiftright's habit of leaving one-bits in the pad space that should be all zeroes, because in a moment of sheer brain fade I'd concluded that only the code path used for not-a-multiple-of-8 shift distances needed to be fixed. Of course, a multiple-of-8 shift distance can also cause the problem, so we need to forcibly zero the extra bits in both cases. Per bug #16037 from Alexander Lakhin. As before, back-patch to all supported branches. Discussion: https://postgr.es/m/16037-1d1ebca564db54f4@postgresql.org
* Fix --dry-run mode of pg_rewindMichael Paquier2019-10-04
| | | | | | | | | | | Even if --dry-run mode was specified, the control file was getting updated, preventing follow-up runs of pg_rewind to work properly on the target data folder. The origin of the problem came from the refactoring done by ce6afc6. Author: Alexey Kondratov Discussion: https://postgr.es/m/7ca88204-3e0b-2f4c-c8af-acadc4b266e5@postgrespro.ru Backpatch-through: 12
* Avoid unnecessary out-of-memory errors during encoding conversion.Tom Lane2019-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Encoding conversion uses the very simplistic rule that the output can't be more than 4X longer than the input, and palloc's a buffer of that size. This results in failure to convert any string longer than 1/4 GB, which is becoming an annoying limitation. As a band-aid to improve matters, allow the allocated output buffer size to exceed 1GB. We still insist that the final result fit into MaxAllocSize (1GB), though. Perhaps it'd be safe to relax that restriction, but it'd require close analysis of all callers, which is daunting (not least because external modules might call these functions). For the moment, this should allow a 2X to 4X improvement in the longest string we can convert, which is a useful gain in return for quite a simple patch. Also, once we have successfully converted a long string, repalloc the output down to the actual string length, returning the excess to the malloc pool. This seems worth doing since we can usually expect to give back several MB if we take this path at all. This still leaves much to be desired, most notably that the assumption that MAX_CONVERSION_GROWTH == 4 is very fragile, and yet we have no guard code verifying that the output buffer isn't overrun. Fixing that would require significant changes in the encoding conversion APIs, so it'll have to wait for some other day. The present patch seems safely back-patchable, so patch all supported branches. Alvaro Herrera and Tom Lane Discussion: https://postgr.es/m/20190816181418.GA898@alvherre.pgsql Discussion: https://postgr.es/m/3614.1569359690@sss.pgh.pa.us
* Allow repalloc() to give back space when a large chunk is downsized.Tom Lane2019-10-03
| | | | | | | | | | | | | | | | | | Up to now, if you resized a large (>8K) palloc chunk down to a smaller size, aset.c made no attempt to return any space to the malloc pool. That's unpleasant if a really large allocation is resized to a significantly smaller size. I think no such cases existed when this code was designed, and I'm not sure whether they're common even yet, but an upcoming fix to encoding conversion will certainly create such cases. Therefore, fix AllocSetRealloc so that it gives realloc() a chance to do something with the block. This doesn't noticeably increase complexity, we mostly just have to change the order in which the cases are considered. Back-patch to all supported branches. Discussion: https://postgr.es/m/20190816181418.GA898@alvherre.pgsql Discussion: https://postgr.es/m/3614.1569359690@sss.pgh.pa.us
* Selectively include window frames in expression walks/mutates.Andrew Gierth2019-10-03
| | | | | | | | | | | | | | | | | | | | query_tree_walker and query_tree_mutator were skipping the windowClause of the query, without regard for the fact that the startOffset and endOffset in a WindowClause node are expression trees that need to be processed. This was an oversight in commit ec4be2ee6 from 2010 which added the expression fields; the main symptom is that function parameters in window frame clauses don't work in inlined functions. Fix (as conservatively as possible since this needs to not break existing out-of-tree callers) and add tests. Backpatch all the way, since this has been broken since 9.0. Per report from Alastair McKinley; fix by me with kibitzing and review from Tom Lane. Discussion: https://postgr.es/m/DB6PR0202MB2904E7FDDA9D81504D1E8C68E3800@DB6PR0202MB2904.eurprd02.prod.outlook.com
* Remove temporary WAL and history files at the end of archive recoveryMichael Paquier2019-10-02
| | | | | | | | | | | | | | | cbc55da has reworked the order of some actions at the end of archive recovery. Unfortunately this overlooked the fact that the startup process needs to remove RECOVERYXLOG (for temporary WAL segment newly recovered from archives) and RECOVERYHISTORY (for temporary history file) at this step, leaving the files around even after recovery ended. Backpatch to 9.5, like the previous commit. Author: Sawada Masahiko Reviewed-by: Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cW4Hsqj+U_R26w3Q@mail.gmail.com Backpatch-through: 9.5
* Stamp 12.0.REL_12_0Tom Lane2019-09-30
|
* Suppress another CR in program outputAndrew Dunstan2019-09-30
| | | | | | This one was exposed by a12c75a10. Backpatch to release 11 where check_pg_config was introduced.
* Doc: improve PREPARE documentation, cross-referencing to plan_cache_mode.Tom Lane2019-09-30
| | | | | | | | The behavior described in the PREPARE man page applies only for the default plan_cache_mode setting, so explain that properly. Rewrite some of the text while I'm here. Per suggestion from Bruce. Discussion: https://postgr.es/m/20190930155505.GA21095@momjian.us
* docs: adjust multi-column most-common-value statisticsBruce Momjian2019-09-30
| | | | | | | | | | This commit adds a mention that the order of columns specified during multi-column most-common-value statistics is insignificant, and tries to simplify examples. Discussion: https://postgr.es/m/20190828162238.GA8360@momjian.us Backpatch-through: 12
* Doc: update v12 release notes.Tom Lane2019-09-30
| | | | Set the release date, make a few adjustments for recent commits.
* Make crash recovery ignore recovery target settings.Fujii Masao2019-09-30
| | | | | | | | | | | | | | | | | | In v11 or before, recovery target settings could not take effect in crash recovery because they are specified in recovery.conf and crash recovery always starts without recovery.conf. But commit 2dedf4d9a8 integrated recovery.conf into postgresql.conf and which unexpectedly allowed recovery target settings to take effect even in crash recovery. This is definitely not good behavior. To fix the issue, this commit makes crash recovery always ignore recovery target settings. Back-patch to v12. Author: Peter Eisentraut Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/e445616d-023e-a268-8aa1-67b8b335340c@pgmasters.net
* jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.Andres Freund2019-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In the course of 5567d12ce03, 356687bd8 and 317ffdfeaac, I changed BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass in the parent node, but NULL. Which in turn prevents the tuple equality comparator from being JIT compiled. While that fixes bug #15486, it is not actually necessary after all of the above commits, as we don't re-build the comparator when using the new BuildTupleHashTableExt() interface (as the content of the hashtable are reset, but the TupleHashTable itself is not). Therefore re-allow jit compilation for callers that use BuildTupleHashTableExt with a separate context for "metadata" and content. As in the previous commit, there's ongoing work to make this easier to test to prevent such regressions in the future, but that infrastructure is not going to be backpatchable. The performance impact of not JIT compiling hashtable equality comparators can be substantial e.g. for aggregation queries that aggregate a lot of input rows to few output rows (when there are a lot of output groups, there will be fewer comparisons). Author: Andres Freund Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de Backpatch: 11, just as 5567d12ce03
* Fix determination when slot types for upper executor nodes are fixed.Andres Freund2019-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | For many queries the fact that the tuple descriptor from the lower node was not taken into account when determining whether the type of a slot is fixed, lead to tuple deforming for such upper nodes not to be JIT accelerated. I broke this in 675af5c01e297. There is ongoing work to enable writing regression tests for related behavior (including a patch that would have detected this regression), by optionally showing such details in EXPLAIN. But as it seems unlikely that that will be suitable for stable branches, just merge the fix for now. While it's fairly close to the 12 release window, the fact that 11 continues to perform JITed tuple deforming in these cases, that there's still cases where we do so in 12, and the fact that the performance regression can be sizable, weigh in favor of fixing it now. Author: Andres Freund Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de Backpatch: 12-, where 675af5c01e297 was merged.
* Translation updatesPeter Eisentraut2019-09-29
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 1d66650d203c89e3c69a18be3b4361f5a5393fcf
* Update list of acknowledgments in release notesPeter Eisentraut2019-09-29
|
* Allow SSL TAP tests to run on WindowsAndrew Dunstan2019-09-29
| | | | | | | Windows does not enforce key file permissions checks in libpq, and psql can produce CRLF line endings on Windows. Backpatch to Release 12 (CRLF) and Release 11 (permissions check)
* doc: Clarify release notes itemPeter Eisentraut2019-09-29
| | | | Reported-by: Justin Pryzby <pryzby@telsasoft.com>
* doc: Further clarify how recovery target parameters are appliedPeter Eisentraut2019-09-29
| | | | | | | | Recovery target parameters are all applied even in standby mode. The previous documentation mostly wished they were not but this was never the case. Discussion: https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b8b335340c%40pgmasters.net
* doc: Release notes refinementsPeter Eisentraut2019-09-29
| | | | In particular, make some more precise links for some major items.
* Fix compilation with older OpenSSL versionsPeter Eisentraut2019-09-28
| | | | | | | | | | | Some older OpenSSL versions (0.9.8 branch) define TLS*_VERSION macros but not the corresponding SSL_OP_NO_* macro, which causes the code for handling ssl_min_protocol_version/ssl_max_protocol_version to fail to compile. To fix, add more #ifdefs and error handling. Reported-by: Victor Wagner <vitus@wagner.pp.ru> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/20190924101859.09383b4f%40fafnir.local.vm
* Improve stability of partition_prune regression test.Tom Lane2019-09-28
| | | | | | | | | | | | | | | | | | This test already knew that, to get stable test output, it had to hide "loops" counts in EXPLAIN ANALYZE results. But that's not nearly enough: if we get a smaller number of workers than we planned for, then the "Workers Launched" number will change, and so will all the rows and loops counts up to the Gather node. This has resulted in repeated failures in the buildfarm, so adjust the test to filter out all these counts. (Really, we wouldn't bother with EXPLAIN ANALYZE at all here, except that currently the only way to verify that executor-time pruning has happened is to look for '(never executed)' annotations. Those are stable and needn't be filtered out.) Back-patch to v11 where the test was introduced. Discussion: https://postgr.es/m/11952.1569536725@sss.pgh.pa.us
* ANALYZE a_star and its children to avoid plan instability in tests.Tom Lane2019-09-27
| | | | | | | | | | | | | | | We've noted certain EXPLAIN queries on these tables occasionally showing unexpected plan choices. This seems to happen because VACUUM sometimes fails to update relpages/reltuples for one of these single-page tables, due to bgwriter or checkpointer holding a pin on the lone page at just the wrong time. To ensure those values get set, insert explicit ANALYZE operations on these tables after we finish populating them. This doesn't seem to affect any other test cases, so it's a usable fix. Back-patch to v12. In principle the issue exists further back, but we have not seen it before v12, so I won't risk back-patching further. Discussion: https://postgr.es/m/24480.1569518042@sss.pgh.pa.us
* Doc: clean up markup for jsonb_set and related functions.Tom Lane2019-09-27
| | | | | | | | | | The markup for optional parameters was neither correct nor consistent. In passing, fix a spelling mistake. Per report from Alex Macy. Some of these mistakes are old, so back-patch as appropriate. Discussion: https://postgr.es/m/156953522258.1204.12736099368284950578@wrigleys.postgresql.org
* doc: Add timeline as valid recovery target in standby.signal documentationPeter Eisentraut2019-09-27
| | | | | | | | | | | The documentation states that no target settings will be used when standby.signal is present, but this is not quite the case since recovery_target_timeline is a valid recovery target for a standby. Update the documentation with this exception. Author: David Steele <david@pgmasters.net> Discussion: https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b8b335340c%40pgmasters.net
* Add tab completion for EXPLAIN (SETTINGS) in psqlMichael Paquier2019-09-27
| | | | | | | Author: Justin Pryzby Reviewed-by: Tatsuro Yamada Discussion: https://postgr.es/m/20190927022051.GC24334@telsasoft.com Backpatch-through: 12
* Fix oversight in commit 4429f6a9e3e12bb4af6e3677fbc78cd80f160252.Amit Kapila2019-09-27
| | | | | | | | | | | | | | The test name and the following test cases suggest the index created should be hash index, but it forgot to add 'using hash' in the test case. This in itself won't improve code coverage as there were some other tests which were covering the corresponding code. However, it is better if the added tests serve their actual purpose. Reported-by: Paul A Jungwirth Author: Paul A Jungwirth Reviewed-by: Mahendra Singh Backpatch-through: 9.4 Discussion: https://postgr.es/m/CA+renyV=Us-5XfMC25bNp-uWSj39XgHHmGE9Rh2cQKMegSj52g@mail.gmail.com
* doc: Fix whitespace in markupPeter Eisentraut2019-09-26
|
* doc: Format example JSON data betterPeter Eisentraut2019-09-26
|
* doc: Update a confusing sentence about SQL/JSONPeter Eisentraut2019-09-26
| | | | | | Author: Liudmila Mantrova <l.mantrova@postgrespro.ru> Reported-by: Jeff Janes <jeff.janes@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAMkU%3D1wP-SO4KpiLxHJuPezTJCmK%3DJqefLXrr3eXFO7Qku%2BtMg%40mail.gmail.com
* doc: Update note about source code formattingPeter Eisentraut2019-09-26
| | | | | | | | | | Update the note about why not to use // comments, even though it's now technically supported. The note about variable declarations was dropped here because it's addressed more properly later in the chapter. Discussion: https://www.postgresql.org/message-id/flat/156924954640.1117.6309209869705522549%40wrigleys.postgresql.org
* doc: Reorder JSON functions documentationPeter Eisentraut2019-09-26
| | | | | | | | Put the description of the SQL/JSON path language after the description of the general JSON functions and operators, instead of before. Discussion: https://www.postgresql.org/message-id/16968.1569189812@sss.pgh.pa.us
* Fix handling of GENERATED columns in CREATE TABLE LIKE INCLUDING DEFAULTS.Tom Lane2019-09-25
| | | | | | | | | | | | | | LIKE INCLUDING DEFAULTS tried to copy the attrdef expression without copying the state of the attgenerated column. This is in fact wrong, because GENERATED and DEFAULT expressions are not the same kind of animal; one can contain Vars and the other not. We *must* copy attgenerated when we're copying the attrdef expression. Rearrange the if-tests so that the expression is copied only when the correct one of INCLUDING DEFAULTS and INCLUDING GENERATED has been specified. Per private report from Manuel Rigger. Tom Lane and Peter Eisentraut
* Doc: Fix example related to partition pruningMichael Paquier2019-09-25
| | | | | | | | | Append node has been removed in v12 when there would be only one subnode under it. Author: Amit Langote Discussion: https://postgr.es/m/CA+HiwqHhS62w8zUFXF4NBjvMboCXYnD-jWoWp-tfo2aHvP3Gxg@mail.gmail.com Backpatch-through: 12
* Fix failure with lock mode used for custom relation optionsMichael Paquier2019-09-25
| | | | | | | | | | | | | | | | | | | | | In-core relation options can use a custom lock mode since 47167b7, that has lowered the lock available for some autovacuum parameters. However it forgot to consider custom relation options. This causes failures with ALTER TABLE SET when changing a custom relation option, as its lock is not defined. The existing APIs to define a custom reloption does not allow to define a custom lock mode, so enforce its initialization to AccessExclusiveMode which should be safe enough in all cases. An upcoming patch will extend the existing APIs to allow a custom lock mode to be defined. The problem can be reproduced with bloom indexes, so add a test there. Reported-by: Nikolay Sharplov Analyzed-by: Thomas Munro, Michael Paquier Author: Michael Paquier Reviewed-by: Kuntal Ghosh Discussion: https://postgr.es/m/20190920013831.GD1844@paquier.xyz Backpatch-through: 9.6
* Fix bug in pairingheap_SpGistSearchItem_cmp()Alexander Korotkov2019-09-25
| | | | | | | | | Our item contains only so->numberOfNonNullOrderBys of distances. Reflect that in the loop upper bound. Discussion: https://postgr.es/m/53536807-784c-e029-6e92-6da802ab8d60%40postgrespro.ru Author: Nikita Glukhov Backpatch-through: 12
* Stamp 12rc1.REL_12_RC1Tom Lane2019-09-23
|
* Doc: more contributor name cleanup.Tom Lane2019-09-23
| | | | | | Further adjust Japanese names, per advice from Etsuro Fujita. Discussion: https://postgr.es/m/CAPmGK15XT8eCwn1j3tB3CnOn2q6ksHNKwKjDrEcca5ZEfG0tng@mail.gmail.com
* Doc: clarify handling of duplicate elements in array containment tests.Tom Lane2019-09-23
| | | | | | | | | The array <@ and @> operators do not worry about duplicates: if every member of array X matches some element of array Y, then X is contained in Y, even if several members of X get matched to the same Y member. This was not explicitly stated in the docs though, so improve matters. Discussion: https://postgr.es/m/156614120484.1310.310161642239149585@wrigleys.postgresql.org
* Doc: proofreading for v12 release notes.Tom Lane2019-09-23
| | | | | | | | Mostly markup improvements, with a couple of grammar fixes. Liudmila Mantrova Discussion: https://postgr.es/m/CAEkD-mDxVV1Hrxzo3-hPaS5b1s-+Gin+9Cbu2eMBqRovRVjC0w@mail.gmail.com
* Doc: clean up some issues with spellings of contributor names.Tom Lane2019-09-23
| | | | | | | | | | In the v12 contributors list, remove a couple of duplicates that had crept in due to variant spellings of a person's name. Try to standardize Japanese names as given-name-first. Alexander Lakhin Discussion: https://postgr.es/m/a8263c91-6a21-61d4-3156-34bf2fe54e15@gmail.com
* Translation updatesPeter Eisentraut2019-09-23
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 8a42b829ebeb8b22db0e3258ec02137f8840b960
* Message style fixesPeter Eisentraut2019-09-23
|
* NLS: Fix backend gettext triggersPeter Eisentraut2019-09-23
| | | | | The backend also needs to pull in translations from the frontend pg_log_*() functions, since some files in src/common/ use those.
* Fix failure to zero-pad the result of bitshiftright().Tom Lane2019-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the bitstring length is not a multiple of 8, we'd shift the rightmost bits into the pad space, which must be zeroes --- bit_cmp, for one, depends on that. This'd lead to the result failing to compare equal to what it should compare equal to, as reported in bug #16013 from Daryl Waycott. This is, if memory serves, not the first such bug in the bitstring functions. In hopes of making it the last one, do a bit more work than minimally necessary to fix the bug: * Add assertion checks to bit_out() and varbit_out() to complain if they are given incorrectly-padded input. This will improve the odds that manual testing of any new patch finds problems. * Encapsulate the padding-related logic in macros to make it easier to use. Also, remove unnecessary padding logic from bit_or() and bitxor(). Somebody had already noted that we need not re-pad the result of bit_and() since the inputs are required to be the same length, but failed to extrapolate that to the other two. Also, move a comment block that once was near the head of varbit.c (but people kept putting other stuff in front of it), to put it in the header block. Note for the release notes: if anyone has inconsistent data as a result of saving the output of bitshiftright() in a table, it's possible to fix it with something like UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol); This has been broken since day one, so back-patch to all supported branches. Discussion: https://postgr.es/m/16013-c2765b6996aacae9@postgresql.org
* Fix typo in tts_virtual_copyslot.Tom Lane2019-09-22
| | | | | | | | | | | The code used the destination slot's natts where it intended to use the source slot's natts. Adding an Assert shows that there is no case in "make check-world" where these counts are different, so maybe this is a harmless bug, but it's still a bug. Takayuki Tsunakawa Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1FD34C0E@G01JPEXMBYT05
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 16:28:02 +0000