Revues de code

Correctifs appliqués

Tom Lane a poussé :

  • Document that we deviate from ISO 8601 by not using 'T' on output. Per discussion, we should explain that we follow RFC 3339 and not really the letter of the ISO 8601 spec for timestamp output format. Mostly Brendan Jurd's wording, though I tweaked it to clarify that we do take 'T' on input. Minor additional copy-editing and markup-tweaking, too.
  • Adjust documentation of ALTER TABLE CLUSTER ON for more consistency. Josh Kupershmidt
  • Update woefully-obsolete comment. The accurate info about what's in a lock file has been in miscadmin.h for some time, so let's just make this comment point there instead of maintaining a duplicative copy.
  • Move postmaster's RemovePgTempFiles call to a less randomly chosen place. There is no reason to do this as early as possible in postmaster startup, and good reason not to do it until we have completely created the postmaster's lock file, namely that it might contribute to pg_ctl thinking that postmaster startup has timed out. (This would require a rather unusual amount of time to be spent scanning temp file directories, but we have at least one field report of it happening reproducibly.) Back-patch to 9.1. Before that, pg_ctl didn't wait for additional info to be added to the lock file, so it wasn't a problem. Note that this is not a complete fix to the slow-start issue in 9.1, because we still had identify_system_timezone being run during postmaster start in 9.1. But that's at least a reasonably well-defined delay, with an easy workaround if needed, whereas the temp-files scan is not so predictable and cannot be avoided.
  • Ensure that seqscans check for interrupts at least once per page. If a seqscan encounters many consecutive pages containing only dead tuples, it can remain in the loop in heapgettup for a long time, and there was no CHECK_FOR_INTERRUPTS anywhere in that loop. This meant there were real-world situations where a query would be effectively uncancelable for long stretches. Add a check placed to occur once per page, which should be enough to provide reasonable response time without adding any measurable overhead. Report and patch by Merlin Moncure (though I tweaked it a bit). Back-patch to all supported branches.
  • Fix array overrun in regex code. zaptreesubs() was coded to unconditionally reset a capture subre's corresponding pmatch[] entry. However, in regexes without backrefs, that array is caller-supplied and might not have as many entries as the regex has capturing parens. So check the array length and do nothing if there is no corresponding entry, much as subset() does. Failure to check this resulted in a stack clobber in the case reported by Marko Kreen. This bug appears to have been latent in the regex library from the beginning. It was not exposed because find() called dissect() not cdissect(), and the dissect() code path didn't ever call zaptreesubs() (formerly zapmem()). When I unified dissect() and cdissect() in commit 4dd78bf37aa29d04b3f358b08c4a2fa43cf828e7, the problem was exposed. Now that I've seen this, I'm rather suspicious that we might need to back-patch it; but will refrain for now, for lack of evidence that the case can be hit in the previous coding.
  • Use binary search instead of brute-force scan in findNamespace(). The previous coding presented a significant bottleneck when dumping databases containing many thousands of schemas, since the total time spent searching would increase roughly as O(N2) in the number of objects. Noted by Jeff Janes, though I rewrote his proposed patch to use the existing findObjectByOid infrastructure. Since this is a longstanding performance bug, backpatch to all supported versions.
  • Fix string truncation to be multibyte-aware in text_name and bpchar_name. Previously, casts to name could generate invalidly-encoded results. Also, make these functions match namein() more exactly, by consistently using palloc0() instead of ad-hoc zeroing code. Back-patch to all supported branches. Karl Schnaitter and Tom Lane
  • Prevent synchronized scanning when systable_beginscan chooses a heapscan. The only interesting-for-performance case wherein we force heapscan here is when we're rebuilding the relcache init file, and the only such case that is likely to be examining a catalog big enough to be syncscanned is RelationBuildTupleDesc. But the early-exit optimization in that code gets broken if we start the scan at a random place within the catalog, so that allowing syncscan is actually a big deoptimization if pg_attribute is large (at least for the normal case where the rows for core system catalogs have never been changed since initdb). Hence, prevent syncscan here. Per my testing pursuant to complaints from Jeff Frost and Greg Sabino Mullane, though neither of them seem to have actually hit this specific problem. Back-patch to 8.3, where syncscan was introduced.

Peter Eisentraut a poussé :

Robert Haas a poussé :

Bruce Momjian a poussé :

Magnus Hagander a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Alexander Korotkov sent in another revision of the patch to add conversion from pg_wchar to multibyte.
  • Gurjeet Singh sent in a patch to add a new syntax allowing joining multiple CREATE INDEX statements with commas, that signifying that the indexes are to be created all in one pass.
  • Heikki Linnakangas sent in a patch to speed up the new buffering GiST build code.
  • Andrew Dunstan sent in a patch to fix a problem with pg_dump and pg_restore --data-only.
  • Marti Raudsepp sent in a patch to mark as "skipped" sorts of 0 or 1 tuple in EXPLAIN.
  • Fujii Masao sent in a patch to add a pg_size_pretty(int) function.
  • Pavel Stehule sent in a patch to add a "shell" output format for psql which optimizes the output for use by the shell.