Revues de code

Correctifs appliqués

Robert Haas a poussé :

Peter Eisentraut a poussé :

Tom Lane a poussé :

  • Another trivial comment-typo fix.
  • Fix edge-case behavior of pg_next_dst_boundary(). Due to rather sloppy thinking (on my part, I'm afraid) about the appropriate behavior for boundary conditions, pg_next_dst_boundary() gave undefined, platform-dependent results when the input time is exactly the last recorded DST transition time for the specified time zone, as a result of fetching values one past the end of its data arrays. Change its specification to be that it always finds the next DST boundary *after* the input time, and adjust code to match that. The sole existing caller, DetermineTimeZoneOffset, doesn't actually care about this distinction, since it always uses a probe time earlier than the instant that it does care about. So it seemed best to me to change the API to make the result=1 and result=0 cases more consistent, specifically to ensure that the "before" outputs always describe the state at the given time, rather than hacking the code to obey the previous API comment exactly. Per bug #6605 from Sergey Burladyan. Back-patch to all supported versions.
  • Fix planner's handling of RETURNING lists in writable CTEs. setrefs.c failed to do "rtoffset" adjustment of Vars in RETURNING lists, which meant they were left with the wrong varnos when the RETURNING list was in a subquery. That was never possible before writable CTEs, of course, but now it's broken. The executor fails to notice any problem because ExecEvalVar just references the ecxt_scantuple for any normal varno; but EXPLAIN breaks when the varno is wrong, as illustrated in a recent complaint from Bartosz Dmytrak. Since the eventual rtoffset of the subquery is not known at the time we are preparing its plan node, the previous scheme of executing set_returning_clause_references() at that time cannot handle this adjustment. Fortunately, it turns out that we don't really need to do it that way, because all the needed information is available during normal setrefs.c execution; we just have to dig it out of the ModifyTable node. So, do that, and get rid of the kluge of early setrefs processing of RETURNING lists. (This is a little bit of a cheat in the case of inherited UPDATE/DELETE, because we are not passing a "root" struct that corresponds exactly to what the subplan was built with. But that doesn't matter, and anyway this is less ugly than early setrefs processing was.) Back-patch to 9.1, where the problem became possible to hit.
  • Modify create_index regression test to avoid intermittent failures. We have been seeing intermittent buildfarm failures due to a query sometimes not using an index-only scan plan, because a background auto-ANALYZE prevented the table's all-visible bits from being set immediately, thereby causing the estimated cost of an index-only scan to go up considerably. Adjust the test case so that a bitmap index scan is preferred instead, which serves equally well for the purpose the test case is actually meant for. (Of course, it would be better to eliminate the interference from auto-ANALYZE, but I see no low-risk way to do that, so any such fix will have to be left for 9.3 or later.)
  • Fix oversight in recent parameterized-path patch. bitmap_scan_cost_est() has to be able to cope with a BitmapOrPath, but I'd taken a shortcut that didn't work for that case. Noted by Heikki. Add some regression tests since this area is evidently under-covered.
  • Improve documentation around historical calendar rules. Get rid of section 8.5.6 (Date/Time Internals), which appears to confuse people more than it helps, and anyway discussion of Postgres' internal datetime calculation methods seems pretty out of place here. Instead, make datatype.sgml just say that we follow the Gregorian calendar (a bit of specification not previously present anywhere in that chapter :-() and link to the History of Units appendix for more info. Do some mild editorialization on that appendix, too, to make it clearer that we are following proleptic Gregorian calendar rules rather than anything more historically accurate. Per a question from Florence Cousin and subsequent discussion in pgsql-docs.
  • Fix syslogger's rotation disable/re-enable logic. If it fails to open a new log file, the syslogger assumes there's something wrong with its parameters (such as log_directory), and stops attempting automatic time-based or size-based log file rotations. Sending it SIGHUP is supposed to start that up again. However, the original coding for that was really bogus, involving clobbering a couple of GUC variables and hoping that SIGHUP processing would restore them. Get rid of that technique in favor of maintaining a separate flag showing we've turned rotation off. Per report from Mark Kirkwood. Also, the syslogger will automatically attempt to create the log_directory directory if it doesn't exist, but that was only happening at startup. For consistency and ease of use, it should do the same whenever the value of log_directory is changed by SIGHUP. Back-patch to all supported branches.
  • Fix printing of whole-row Vars at top level of a SELECT targetlist. Normally whole-row Vars are printed as "tabname.*". However, that does not work at top level of a targetlist, because per SQL standard the parser will think that the "*" should result in column-by-column expansion; which is not at all what a whole-row Var implies. We used to just print the table name in such cases, which works most of the time; but it fails if the table name matches a column name available anywhere in the FROM clause. This could lead for instance to a view being interpreted differently after dump and reload. Adding parentheses doesn't fix it, but there is a reasonably simple kluge we can use instead: attach a no-op cast, so that the "*" isn't syntactically at top level anymore. This makes the printing of such whole-row Vars a lot more consistent with other Vars, and may indeed fix more cases than just the reported one; I'm suspicious that cases involving schema qualification probably didn't work properly before, either. Per bug report and fix proposal from Abbas Butt, though this patch is quite different in detail from his. Back-patch to all supported versions.
  • Clear I/O timing counters after sending them to the stats collector. This oversight caused the reported times to accumulate in an O(N2) fashion the longer a backend runs.
  • Adjust timing units in pg_stat_statements. Display total time and I/O timings in milliseconds, for consistency with the units used for timings in the core statistics views. The columns remain of float8 type, so that sub-msec precision is available. (At some point we will probably want to convert the core views to use float8 type for the same reason, but this patch does not touch that issue.) This is a release-note-requiring change in the meaning of the total_time column. The I/O timing columns are new as of 9.2, so there is no compatibility impact from redefining them. Do some minor copy-editing in the documentation, too.
  • Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
  • Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
  • Rename track_iotiming GUC to track_io_timing. This spelling seems significantly more readable to me.
  • Rename I/O timing statistics columns to blk_read_time and blk_write_time. This seems more consistent with the pre-existing choices for names of other statistics columns. Rename assorted internal identifiers to match.

Bruce Momjian a poussé :

Correctifs rejetés (à ce jour)

  • Pas de déception cette semaine :-)

Correctifs en attente

  • Zoltan Boszormenyi sent in another version of the patches to create a lock timeout framework and use same.
  • Alexander Korotkov sent in a patch to convert from pg_wchar to multibyte, and Erik Rijkers followed up with some regression tests for same.
  • KaiGai Kohei sent in another revision of the patch to add generic extra daemons.
  • Noah Misch sent in a patch to fix an issue where psql does not include a row count when auto-expanded output (\x auto) is set.
  • Kevin Grittner sent in a patch to fix an issue where setting defautl_transaction_isolation to serializable (SSI) broke Hot Standbys.
  • Robert Haas sent in a patch to modify "smart" shutdown mode to disconnect sessions that are not in a transaction (or as soon as they no longer are) but leaves in-progress transactions alone;
  • Noah Misch sent in a patch to allow TEMP tables on a hot standby.