Correctifs appliqués

Tom Lane a poussé :

  • Fix some more bugs in contrib/xml2's xslt_process(). It failed to check for error return from xsltApplyStylesheet(), as reported by Peter Gagarinov. (So far as I can tell, libxslt provides no convenient way to get a useful error message in failure cases. There might be some inconvenient way, but considering that this code is deprecated it's hard to get enthusiastic about putting lots of work into it. So I just made it say "failed to apply stylesheet", in line with the existing error checks.) While looking at the code I also noticed that the string returned by xsltSaveResultToString was never freed, resulting in a session-lifespan memory leak. Back-patch to all supported versions. http://git.postgresql.org/pg/commitdiff/d9b31e4859df5325b7d3d2cc94b0e907f1cf1d3e
  • Fix bogus handling of control characters in json_lex_string(). The original coding misbehaved if "char" is signed, and also made the extremely poor decision to print control characters literally when trying to complain about them. Report and patch by Shigeru Hanada. In passing, also fix core dump risk in report_parse_error() should the parse state be something other than what it expects. http://git.postgresql.org/pg/commitdiff/3dd8e596812e3adb72aecafb23fbb6a30836c475
  • Do unlocked prechecks in bufmgr.c loops that scan the whole buffer pool. DropRelFileNodeBuffers, DropDatabaseBuffers, FlushRelationBuffers, and FlushDatabaseBuffers have to scan the whole shared_buffers pool because we have no index structure that would find the target buffers any more efficiently than that. This gets expensive with large NBuffers. We can shave some cycles from these loops by prechecking to see if the current buffer is interesting before we acquire the buffer header lock. Ordinarily such a test would be unsafe, but in these cases it should be safe because we are already assuming that the caller holds a lock that prevents any new target pages from being loaded into the buffer pool concurrently. Therefore, no buffer tag should be changing to a value of interest, only away from a value of interest. So a false negative match is impossible, while a false positive is safe because we'll recheck after acquiring the buffer lock. Initial testing says that this speeds these loops by a factor of 2X to 3X on common Intel hardware. Patch for DropRelFileNodeBuffers by Jeff Janes (based on an idea of Heikki's); extended to the remaining sequential scans by Tom Lane http://git.postgresql.org/pg/commitdiff/e8d029a30b5a5fb74b848a8697b1dfa3f66d9697
  • Scan the buffer pool just once, not once per fork, during relation drop. This provides a speedup of about 4X when NBuffers is large enough. There is also a useful reduction in sinval traffic, since we only do CacheInvalidateSmgr() once not once per fork. Simon Riggs, reviewed and somewhat revised by Tom Lane http://git.postgresql.org/pg/commitdiff/ece01aae479227d9836294b287d872c5a6146a11

Magnus Hagander a poussé :

Robert Haas a poussé :

  • Fix more crash-safe visibility map bugs, and improve comments. In lazy_scan_heap, we could issue bogus warnings about incorrect information in the visibility map, because we checked the visibility map bit before locking the heap page, creating a race condition. Fix by rechecking the visibility map bit before we complain. Rejigger some related logic so that we rely on the possibly-outdated all_visible_according_to_vm value as little as possible. In heap_multi_insert, it's not safe to clear the visibility map bit before beginning the critical section. The visibility map is not crash-safe unless we treat clearing the bit as a critical operation. Specifically, if the transaction were to error out after we set the bit and before entering the critical section, we could end up writing the heap page to disk (with the bit cleared) and crashing before the visibility map page made it to disk. That would be bad. heap_insert has this correct, but somehow the order of operations got rearranged when heap_multi_insert was added. Also, add some more comments to visibilitymap_test, lazy_scan_heap, and IndexOnlyNext, expounding on concurrency issues. Per extensive code review by Andres Freund, and further review by Tom Lane, who also made the original report about the bogus warnings. http://git.postgresql.org/pg/commitdiff/b50991eedb458a81d875d049f48fb62ab1685c0d
  • When using libpq URI syntax, error out on invalid parameter names. Dan Farina http://git.postgresql.org/pg/commitdiff/3b5548a3d524e3b37d49f79f707d2119ecdfa303

Simon Riggs a poussé :

Peter Eisentraut a poussé :

Bruce Momjian a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Fujii Masao sent in another revision of the patch to fix incorrect handling of the timeout in pg_receivexlog.
  • Ants Aasma sent in another revision of the lockfree getbuffer patch.
  • Robert Haas sent in a patch to remove the heap check when creating objects in pg_catalog.
  • Kyotaro HORIGUCHI sent in a patch to add a new WalRcvStarted() function to check whether streaming replication is on and to determine whether to delay checkpoints using GetLogReplayRecPtr() when WalRcvStarted() it returns true.
  • Robert Haas sent in two revisions of a patch to add a log_newpage_buffer() function and reshuffle responsibility for using it.
  • Kyotaro HORIGUCHI sent in a patch to skip checkpoint on promoting from streaming replication.
  • Amit Kapila sent in a WIP patch to provide a fallback_application_name in pgbench.
  • Dean Rasheed sent in a patch to improve the error hint from DROP FUNCTION in the case of a conflicting function by including the command which would allow dropping the old function in same.
  • Noah Misch sent in a patch which does the unlink() for DROP after releasing existing locks.
  • Jeff Janes sent in a patch to fix cases of quadratic behavior in pg_dump on a large number of objects.