- 26 4月, 2012 5 次提交
-
-
由 Tom Lane 提交于
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.
-
由 Tom Lane 提交于
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.
-
由 Robert Haas 提交于
-
由 Tom Lane 提交于
-
由 Peter Eisentraut 提交于
-
- 25 4月, 2012 3 次提交
-
-
由 Peter Eisentraut 提交于
Predominant standard is two spaces, so adjust outliers to that.
-
由 Peter Eisentraut 提交于
A few simplifications and stylistic improvements, found while grepping around for makefile problems elsewhere.
-
由 Peter Eisentraut 提交于
-
- 24 4月, 2012 6 次提交
-
-
由 Robert Haas 提交于
Prohibiting this outright would break dumps taken from older versions that contain such casts, which would create far more pain than is justified here. Per report by Jaime Casanova and subsequent discussion.
-
由 Robert Haas 提交于
Noted by Guillaume Smet.
-
由 Robert Haas 提交于
Josh Kupershmidt
-
由 Robert Haas 提交于
We must set the visibility map bit before releasing our exclusive lock on the heap page; otherwise, someone might clear the heap page bit before we set the visibility map bit, leading to a situation where the visibility map thinks the page is all-visible but it's really not. This problem has existed since 8.4, but it wasn't critical before we had index-only scans, since the worst case scenario was that the page wouldn't get vacuumed until the next scan_all vacuum. Along the way, a couple of minor, related improvements: (1) if we pause the heap scan to do an index vac cycle, release any visibility map page we're holding, since really long-running pins are not good for a variety of reasons; and (2) warn if we see a page that's marked all-visible in the visibility map but not on the page level, since that should never happen any more (it was allowed in previous releases, but not in 9.2).
-
由 Robert Haas 提交于
The size is only a hint, but a big hint chews up a lot of memory without apparently improving performance much. Analysis and patch by Noah Misch.
-
由 Robert Haas 提交于
Fix typo spotted by Thom Brown, and improve wording in another area where Thom spotted a typo.
-
- 23 4月, 2012 1 次提交
-
-
由 Peter Eisentraut 提交于
Josh Kupershmidt
-
- 21 4月, 2012 3 次提交
-
-
由 Tom Lane 提交于
Instead of an exact cost comparison, use a fuzzy comparison with 1e-10 delta after all other path metrics have proved equal. This is to avoid having platform-specific roundoff behaviors determine the choice when two paths are really the same to our cost estimators. Adjust the recently-added test case that made it obvious we had a problem here.
-
由 Alvaro Herrera 提交于
The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd2, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
-
由 Tom Lane 提交于
For an initial relation that lacks any join clauses (that is, it has to be cartesian-product-joined to the rest of the query), we considered only cartesian joins with initial rels appearing later in the initial-relations list. This creates an undesirable dependency on FROM-list order. We would never fail to find a plan, but perhaps we might not find the best available plan. Noted while discussing the logic with Amit Kapila. Improve the comments a bit in this area, too. Arguably this is a bug fix, but given the lack of complaints from the field I'll refrain from back-patching.
-
- 20 4月, 2012 2 次提交
-
-
由 Tom Lane 提交于
This patch adjusts the treatment of parameterized paths so that all paths with the same parameterization (same set of required outer rels) for the same relation will have the same rowcount estimate. We cache the rowcount estimates to ensure that property, and hopefully save a few cycles too. Doing this makes it practical for add_path_precheck to operate without a rowcount estimate: it need only assume that paths with different parameterizations never dominate each other, which is close enough to true anyway for coarse filtering, because normally a more-parameterized path should yield fewer rows thanks to having more join clauses to apply. In add_path, we do the full nine yards of comparing rowcount estimates along with everything else, so that we can discard parameterized paths that don't actually have an advantage. This fixes some issues I'd found with add_path rejecting parameterized paths on the grounds that they were more expensive than not-parameterized ones, even though they yielded many fewer rows and hence would be cheaper once subsequent joining was considered. To make the same-rowcounts assumption valid, we have to require that any parameterized path enforce *all* join clauses that could be obtained from the particular set of outer rels, even if not all of them are useful for indexing. This is required at both base scans and joins. It's a good thing anyway since the net impact is that join quals are checked at the lowest practical level in the join tree. Hence, discard the original rather ad-hoc mechanism for choosing parameterization joinquals, and build a better one that has a more principled rule for when clauses can be moved. The original rule was actually buggy anyway for lack of knowledge about which relations are part of an outer join's outer side; getting this right requires adding an outer_relids field to RestrictInfo.
-
由 Peter Eisentraut 提交于
Like with SGML files, using tabs in these files is confusing and unnecessary.
-
- 18 4月, 2012 10 次提交
-
-
由 Robert Haas 提交于
This has been wrong for a really long time. We don't use two-phase locking to protect against serialization anomalies. Per discussion on pgsql-hackers about 2011-03-07; original report by Dan Ports.
-
由 Robert Haas 提交于
Commit 8e5ac74c tried to do this renaming, but I relied on gcc to tell me where I needed to make changes, instead of grep. Noted by Jeff Davis.
-
由 Robert Haas 提交于
The previous code could cause a backend crash after BEGIN; SAVEPOINT a; LOCK TABLE foo (interrupted by ^C or statement timeout); ROLLBACK TO SAVEPOINT a; LOCK TABLE foo, and might have leaked strong-lock counts in other situations. Report by Zoltán Böszörményi; patch review by Jeff Davis.
-
由 Robert Haas 提交于
Noah Misch spotted the fact that the old comment is in fact incorrect, due to memory ordering hazards.
-
由 Robert Haas 提交于
Previously, we used SetBufferCommitInfoNeedsSave, but that's really intended for dirty-marks we can theoretically afford to lose, such as hint bits. As for 9.2, the PD_ALL_VISIBLE mustn't be lost in this way, since we could then end up with a heap page that isn't all-visible and a visibility map page that is all visible, causing index-only scans to return wrong answers.
-
由 Robert Haas 提交于
Noah Misch
-
由 Robert Haas 提交于
Mostly, this consists of adding support for fields which exist in the structure but aren't handled by copy/equal/outfuncs; but the create foreign table case can actually produce garbage output. Noah Misch
-
由 Robert Haas 提交于
Fujii Masao
-
由 Peter Eisentraut 提交于
Previously, the use of the optional key word WITH was not supported. Josh Kupershmidt
-
由 Andrew Dunstan 提交于
A number of utility programs were rather careless about paremeters that can be set via both an option argument and a positional argument. This leads to results which can violate the Principal Of Least Astonishment. These changes refuse to use positional arguments to override settings that have been made via positional arguments. The changes are backpatched to all live branches.
-
- 17 4月, 2012 2 次提交
-
-
由 Heikki Linnakangas 提交于
When using synchronous replication, we waited for the commit record to be replicated, but if we our transaction didn't write any other WAL records, that's not required because we don't even flush the WAL locally to disk in that case. This lead to long waits when committing a transaction that only modified a temporary table. Bug spotted by Thom Brown.
-
由 Peter Eisentraut 提交于
-
- 16 4月, 2012 4 次提交
-
-
由 Peter Eisentraut 提交于
Kyotaro HORIGUCHI
-
由 Heikki Linnakangas 提交于
The header file is needed by any module that wants to use the PL/pgSQL instrumentation plugin interface. Most notably, the pldebugger plugin needs this. With this patch, it can be built using pgxs, without having the full server source tree available.
-
由 Peter Eisentraut 提交于
Clarify that nrows() is the number of rows processed, versus the number of rows returned, which can be obtained using len. Also add tests about that.
-
由 Peter Eisentraut 提交于
The result object methods colnames() etc. would crash when called after a command that did not produce a result set. Now they throw an exception. discovery and initial patch by Jean-Baptiste Quenot
-
- 15 4月, 2012 1 次提交
-
-
由 Tatsuo Ishii 提交于
message. They are already implemented in the source code. Suggestions about the message formatting from Tom Lane.
-
- 14 4月, 2012 3 次提交
-
-
由 Robert Haas 提交于
Fujii Masao, per discussion on pgsql-hackers
-
由 Robert Haas 提交于
The output of the new pg_xlog_location_diff function is of type numeric, since it could theoretically overflow an int8 due to signedness; this provides a convenient way to format such values. Fujii Masao, with some beautification by me.
-
由 Tatsuo Ishii 提交于
discussion of hackers list on 2012/3/10 "missing description initdb manual".
-