ProcessUtility can recurse, and indeed can be driven to infinite recursion, so it ought to have a check_stack_depth() call. This covers the reported bug (portal trying to execute itself) and a bunch of other cases that could perhaps arise somewhere. Per bug #15428 from Malthe Borch. Back-patch to all supported branches. Discussion: https://postgr.es/m/15428-b3c2915ec470b033@postgresql.org
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 63764ec4ef426dc469efe1cbcd9f2c45ef9fbe95
With the PostgreSQL 11 release notes acknowledgments list, FOP reported WARNING: Glyph "?" (0x144, nacute) not available in font "Times-Roman". WARNING: Glyph "?" (0x15e, Scedilla) not available in font "Times-Roman". WARNING: Glyph "?" (0x15f, scedilla) not available in font "Times-Roman". WARNING: Glyph "?" (0x131, dotlessi) not available in font "Times-Roman". This is because we have some new contributors whose names use letters that we haven't used before, and apparently FOP can't handle them out of the box. For now, just fix this by "unaccenting" those names. In the future, maybe this can be fixed better with a different font configuration. There is also another warning WARNING: Glyph "?" (0x3c0, pi) not available in font "Times-Roman". but that existed in previous releases and is not touched here.
This commit documents rounding of "length" parameter and absence of support for unique indexes and NULLs searching. Backpatch to 9.6 where contrib/bloom was introduced. Discussion: https://postgr.es/m/CAF4Au4wPQQ7EHVSnzcLjsbY3oLSzVk6UemZLD1Sbmwysy3R61g%40mail.gmail.com Author: Oleg Bartunov with minor editorialization by me Backpatch-through: 9.6
On a primary, sets of XLOG_RUNNING_XACTS records are generated on a periodic basis to allow recovery to build the initial state of transactions for a hot standby. The set of transaction IDs is created by scanning all the entries in ProcArray. However it happens that its logic never counted on the fact that two-phase transactions finishing to prepare can put ProcArray in a state where there are two entries with the same transaction ID, one for the initial transaction which gets cleared when prepare finishes, and a second, dummy, entry to track that the transaction is still running after prepare finishes. This way ensures a continuous presence of the transaction so as callers of for example TransactionIdIsInProgress() are always able to see it as alive. So, if a XLOG_RUNNING_XACTS takes a standby snapshot while a two-phase transaction finishes to prepare, the record can finish with duplicated XIDs, which is a state expected by design. If this record gets applied on a standby to initial its recovery state, then it would simply fail, so the odds of facing this failure are very low in practice. It would be tempting to change the generation of XLOG_RUNNING_XACTS so as duplicates are removed on the source, but this requires to hold on ProcArrayLock for longer and this would impact all workloads, particularly those using heavily two-phase transactions. XLOG_RUNNING_XACTS is also actually used only to initialize the standby state at recovery, so instead the solution is taken to discard duplicates when applying the initial snapshot. Diagnosed-by: Konstantin Knizhnik Author: Michael Paquier Discussion: https://postgr.es/m/0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ru Backpatch-through: 9.3
Justin Pryzby and myself. Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com
6e7baa3227 and b06d8e58b5 added "B" as a valid suffix for GUC_UNIT_BYTES but neglected to add it to the docs.
Justin Pryzby, Jonathan S. Katz, and myself. Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com
Justin Pryzby, Jonathan S. Katz, and myself. Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com