- 03 6月, 2016 7 次提交
-
-
由 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 3 次提交
-
-
由 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.
-
由 Heikki Linnakangas 提交于
prev_item variable needs to be reset between the two loops. Otherwise, if the first item in the latter list (allocatedReaderGangs1) needs to be removed, things go wrong. I got an assertion failure with installcheck-good from that: FailedAssertion(""!(prev != ((void *)0) ? ((prev)->next) == cell : list_head(list) == cell)"", File: ""list.c"", Line: 616) This got broken in the recent refactoring commit 46dfa750. The rest of the changes in this commit, introducing the new next_item variable, wasn't needed for correctness, but IMHO makes the code easier to understand.
-
由 Heikki Linnakangas 提交于
I missed this in commit af7b1b51, which reverted the backend shutdown code closer to the upstream. Without it, auxiliary proc slots are never reused, so you run out of them fairly quickly, if any (non-permanent) auxiliary processes are used. Reported by Gang Xiong, who ran into this with gprecoverseg.
-
- 28 5月, 2016 2 次提交
-
-
由 Heikki Linnakangas 提交于
The checks for invalid TIDs are very cheap, a few CPU instructions. It's better to catch bugs involving invalid TID early, so let's always check for them. The LOGs in storeAttrDefault() that were also tied to this GUC seemed oddly specific. They were probably added long time ago to hunt for some particular bug, and don't seem generally useful, so I just removed them.
-
由 Jamie McAtamney 提交于
Previously, the functions and subclasses in gpcrondump, gpdbrestore, dump.py, and restore.py all required long lists of arguments to be passed around and required many helper functions. This made adding new command-line options or new features quite time-consuming to implement and to test. Now, a Context class has been added to backup_utils.py that holds all of the variables used for command-line options, as well as other variables used in many places during backup and restore; additionally, many helper functions have been condensed into a few functions within Context, and in the future more such functions can be moved to Context as needed. This will make it much easier to expand dump and restore functionality going forward.
-
- 27 5月, 2016 1 次提交
-
-
由 Kenan Yao 提交于
-