Argentina, Bahamas, Brazil, Mauritius, Morocco, Pakistan, Palestine, Paraguay).
forestalls potential overflow when the same table (or other object, but usually tables) is accessed by very many successive queries within a single transaction. Per report from Michael Milligan. Back-patch to 8.0, which is as far back as the patch conveniently applies. There have been no reports of overflow in pre-8.3 releases, but clearly the risk existed all along. (Michael's report suggests that 8.3 may consume lock counts faster than prior releases, but with no test case to look at it's hard to be sure about that. Widening the counts seems a good future-proofing measure in any event.)
GetOldestXmin() instead of RecentGlobalXmin; this is safer because we do not depend on the latter being correctly set elsewhere, and while it is more expensive, this code path is not performance-critical. This is a real risk for autovacuum, because it can execute whole cycles without doing a single vacuum, which would mean that RecentGlobalXmin would stay at its initialization value, FirstNormalTransactionId, causing a bogus value to be inserted in pg_database. This bug could explain some recent reports of failure to truncate pg_clog. At the same time, change the initialization of RecentGlobalXmin to InvalidTransactionId, and ensure that it's set to something else whenever it's going to be used. Using it as FirstNormalTransactionId in HOT page pruning could incur in data loss. InitPostgres takes care of setting it to a valid value, but the extra checks are there to prevent "special" backends from behaving in unusual ways. Per Tom Lane's detailed problem dissection in 29544.1221061979@sss.pgh.pa.us
whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
at once and ItemPointers are collected in memory. Remove tuple's killing by killtuple() if tuple was moved to another page - it could produce unaceptable overhead. Backpatch up to 8.1 because the bug was introduced by GiST's concurrency support.
Per Microsoft knowledge base article Q201213, early versions of Windows fail when we do this. Later versions of Windows appear to have a higher limit than 64Kb, but do still fail on large sends, so we unconditionally limit it for all versions. Patch from Tom Lane.
returns NULL instead of a PGresult. The former coding would fail, which is OK, but it neglected to give you the PQerrorMessage that might tell you why. In the oldest branches, there was another problem: it'd sometimes report PQerrorMessage from the wrong connection.