- 03 6月, 2016 12 次提交
-
-
由 Heikki Linnakangas 提交于
The multiset_5 function returns a "SET OF example", but the 'a' column was dropped from 'example' table earlier. The statement currently produces a different error, because anytable cannot be passed to PREPARE, but if that worked, this would fail because of the broken ORDER BY. The purpose of this test is to test PREPARE with anytable, so let's not have a broken ORDER BY.
-
由 Heikki Linnakangas 提交于
Just to keep the normal expected output and ORCA expected output as close to each other as possible. You do get those NOTICEs when you run the queries, but they are ignored thanks to the "init-file" we use.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
Reformat some of the test queries, and make sure the formatting is the same between the .sql file and .out file (pg_regress uses "diff -w", which masks out some of the differences, but it was annoying while doing a manual diff).
-
由 Heikki Linnakangas 提交于
pg_regress uses gpdiff.pl to mask differences in costs etc. of EXPLAIN output, so that trivial changes in the plan output don't cause a regression failure. That mechanism didn't work for this EXPLAIN query, because the "explain" and "select" were on different lines. Remove the newline, to make gpdiff.pl recognize the query as an EXPLAIN query, to make the test case less fragile.
-
由 Heikki Linnakangas 提交于
I noticed while debugging an issue with PartitionSelectors on the 8.3 merge branch, that we don't have a test case for this.
-
由 Heikki Linnakangas 提交于
Commit 879de2bc added a test case for naming output columns of append nodes, but forgot to update the non-ORCA expected output.
-
由 Heikki Linnakangas 提交于
Seems more straightforward. Firstly, modifying a PlannedStmt at execution is dubious, if the PlannedStmt is reused for executing the same query again. Secondly, if the original Query objects are indeed not needed after planning, we can save a little bit of memory, and avoid the overhead of stripping the plan on every execution. This also makes any breakage more obvious, if it turns out that the Query is actually still needed at execution for some reason, as that issue would then show up on the first execution already, and not only on reuse of a PlannedStmt. Per Kenan Yao's observation that stripPlanBeforeDispatch() also scribbles on the PlannedStmt.
-
由 Heikki Linnakangas 提交于
This is also transient information, only valid during execution, and should not be cached with the plan.
-
由 Heikki Linnakangas 提交于
That includes the slice table, transientRecordTypes, and IntoClause's oidInfo. These are transient information, created in ExecutorStart, not something that should be cached along with the plan. transientRecordTypes and oidInfo in particular were stored in PlannedStmt only so that they can be conveniently dispatched to QEs along with the plan. That's not a problem at the moment, but with the upcoming PostgreSQL 8.3 merge, we'll start keeping the PlannedStmt struct around for many executions, so let's create a new struct to hold that kind of information, which is transmitted from QD to QEs along with the plan (that new struct is called QueryDispatchDesc).
-
由 Heikki Linnakangas 提交于
This isn't a problem right now, but with PostgreSQL 8.3, PlannedStmt is supposed to be immutable, because plan caching works by saving the PlannedStmt. So let's tidy this up, before we merge that from the upstream. There are more GPDB-added fields in there that are modified, but this is a start.
-
由 Heikki Linnakangas 提交于
If there are two InitPlan nodes inside each other, and the outer InitPlan never executes the inner InitPlan (because the value of the outer InitPlan was determined without it), don't get confused when some of the params are not set (= won't even have a valid type OID) bfv_subquery regression tests exercised this. It failed with --enable-cassert. Fixes github issue #500.
-
- 02 6月, 2016 19 次提交
-
-
This fixes the test failure introduced in commit effc38f6 fixes #809 [delivers #120723853]
-
由 Nikos Armenatzoglou 提交于
This commit generates code for a naive code-generated version of ExecQual that simply fallbacks to regular ExecQual. The code-generated ExecQual is enrolled in the existing codegen framework and is called only in ExecScan. After the implementation of the function (i.e., generate code for expression evaluation), we can replace all calls to regular ExecQual with call_ExecQual macros.
-
由 Shreedhar Hardikar 提交于
* Address a number of cpplint errors * Fix files and variable naming for ExecVariableList codegen * Ignore Testing directory created by ctest
-
由 Heikki Linnakangas 提交于
The 8.3 merge added a new opr_sanity test that caught that. But it's been broken all along, so fix it now. We'll get the regression test later, with the merge.
-
由 Heikki Linnakangas 提交于
Backport this bugfix from PostgreSQL 9.0, because we had backported src/timezone or at least localtime.c from 9.0. This brings localtime.c in sync with the tip of REL9_0_STABLE. (PostgreSQL 9.0 is end-of-life already, so there won't be any more fixes in that branch in the upstream.) commit 6b87144323fe4cf920ea4d095cce93a84c9b8922 Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Wed Apr 25 17:25:30 2012 -0400 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.
-
由 Heikki Linnakangas 提交于
This was useful while debugging on the 8.3 merge branch. It might come handy in the future too, and it's cheap.
-
由 Daniel Gustafsson 提交于
-
由 Heikki Linnakangas 提交于
The convenience routine isn't really all that convenient. Aside from refactoring, this turns the NULL checks from an Assert to elog(). Seems more robust. (I happened to hit the assertion, while hacking on something else.)
-
由 Heikki Linnakangas 提交于
This was done in the upstream earlier already, in commit 8b4ff8b6, but there were a few GPDB-added error messages left. Fix those too, for consistency.
-
由 Heikki Linnakangas 提交于
This is inside an if-check that checks the same. Plus some whitespace fixes. Caught my eye while debugging..
-
由 Heikki Linnakangas 提交于
There's no need to be able to read nodes generated by an old version. We're not going to handle upgrades that way.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
Not strictly necessary, but couldn't resist..
-
由 Heikki Linnakangas 提交于
The VERBOSE option was always ignored, so this is no loss in functionality, you just can't add that noiseword there anymore. According to git history, this was added to the syntax back in 2009, for "PostgreSQL compatibility", but AFAICS PostgreSQL has never had VERBOSE option for CLUSTER, so I have no idea what that was all about. It's possibly worth noting in release notes as a backwards-incompatibility, though.
-
由 Heikki Linnakangas 提交于
Having a "checkpoint.h", corresponding to "checkpoint.c", makes perfect sense, but those function definitions are in bgwriter.h in PostgreSQL, and keeping the code as close to upstream as possible trumps the consistency of keeping definitions for "foo.c" in header file called "foo.h". Keeping things close to upstream makes merging easier.
-
由 Heikki Linnakangas 提交于
These created merge conflicts while working on the 8.3 merge. In order to keep that upcoming big merge slightly smaller, cherry-pick this change to master now. pg_depend.c was already completely identical to the PostgreSQL 8.3 version, except for the use of CaQL. Well, almost: there was also one instance of changing an old heap_formtuple() call to the new heap_form_tuple() interface. I kept that change. But other than that, the file is now 100% identical to upstream.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
We don't particularly care about performance on Solaris at the moment, and have no Solaris systems to test on. Let's just rely on the upstream defaults, and revert this change to reduce our diff footprint vs. upstream.
-
-
- 01 6月, 2016 8 次提交
-
-
由 Dan Lynch 提交于
-
由 Heikki Linnakangas 提交于
If a page has hint bits set, but the buffer has not been marked as dirty, and it gets evicted between the 1st and 2nd vacuum pass, the 2nd pass gets upset. That can't happen in the upstream, as setting a hint bit always marks the buffer as dirty, but that is not guaranteed in GPDB, because of gp_disable_tuple_hints.
-
由 Shreedhar Hardikar 提交于
Includes tests: composite_keys_gpdb_1 composite_keys_gpdb_3 composite_keys_gpdb_2 partitionindexes staticselection cte_functest cte_queries create_table_default_distribution lastj lastj_hash indexapply
-
由 Heikki Linnakangas 提交于
Commit 33a1278c merged upstream addition of a typmod argument to makeConst(). However, one of the calls was botched during the merge, and the typmod argument was inserted to wrong place in argument list. This seems to have been harmless because the constant ended up being NULL anyway, and the bogus values for the other arguments were ignored.
-
由 Heikki Linnakangas 提交于
These got in the way in the PostgreSQL 8.3 merge, so let's get them over with before the big merge lands.
-
由 Heikki Linnakangas 提交于
This makes no difference at runtime, as the argument is always passed as NULL anyway, but let's avoid unnecessary differences vs. upstream.
-
由 Heikki Linnakangas 提交于
These changes were lifted from upcoming PostgreSQL 8.3 merge branch, but are not related to the merge per se, so let's get them out of the way before the big merge lands. Plus other cosmetic things in neighbouring code that stuck my eye.
-
由 Heikki Linnakangas 提交于
-
- 29 5月, 2016 1 次提交
-
-
由 Heikki Linnakangas 提交于
A new regression test was added in the upstream that does work_mem='64kB', which used to fail without --enable-cassert. There's little reason to not allow a small value here, so let's just allow it. It doesn't mean that anyone should use such a small value in production, but that's just a matter of "don't do that then". The minimum was changed later in the upstream, too, to be 64 kb regardless of BLCKSZ.
-