- 25 1月, 2016 1 次提交
-
-
由 Heikki Linnakangas 提交于
It was quite clearly broken, as it didn't do anything with the new_tle that it chased up, and the end result was just the same as calling canonicalize_pathkeys() on the input.
-
- 22 1月, 2016 2 次提交
-
-
由 Heikki Linnakangas 提交于
I'm not 100% the code is doing the right thing even with this: If the pathkey's operator family doesn't match the join clause's operator family, the output isn't truly ordered the same way. This is not an issue for the case that I included in the regression test, where the join happens on a constant, but I can't figure out whether this might be an issue with some other query.
-
由 Heikki Linnakangas 提交于
The comment in apply_shareinput_xslice() said that we process top-plan first, to ensure that we find the producer of a shared scan before its consumers, when the top plan contains a producer for subplans. But the situation can just as well be the other way 'round. No new test case added, because running the existing with_clause test with gp_cte_sharing=on trips the assertion. Fixes github issue #287.
-
- 19 1月, 2016 3 次提交
-
-
由 Heikki Linnakangas 提交于
int2vector and aclitem don't have B-tree operators, making them not mergejoinable. In the merge of the equivalence classes patch, I made cdb_make_pathkeys_for_expr() more strict on that, and it now throws an error if it's passed a datatype that doesn't have a mergejoinable = operator. It used to return a path key with InvalidOid as the sort operator, but that seems like a recipe for bugs elsehere. To fix, mandate that all gpdb-hashable datatypes must be mergejoinable. int2vector and aclitem are not, so forbid using them in DISTRIBUTED BY. This is a backwards-incompatible change, but hopefully no-one is using int2vector or aclitem in user-tables, at least not as a distribution key.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
This is dead, because SubPlan is an Expr node and therefore cannot appear in a Plan tree. This was broken, because the "subplan = (SubPlan *) subplan" cast didn't do anything, and subplan was potentially uninitialized. It meant to say "subplan = (SubPlan *) plan". Spotted by Daniel Gustafsson.
-
- 18 1月, 2016 2 次提交
-
-
由 Heikki Linnakangas 提交于
parser/analyze.c is bloated, moving larger chunks of GPDB-specific functionality like this elsewhere makes it more readable. Make diffing and merging of analyze.c with upstream easier, too. I also ran pgindent on parse_partition.c.
-
由 Heikki Linnakangas 提交于
parser/analyze.c is overcrowded, and since it's an upstream file, extra code there can confuse merging (though completely new functions are less of a problem).
-
- 14 1月, 2016 1 次提交
-
-
由 Goden Yao 提交于
-
- 12 1月, 2016 1 次提交
-
-
由 Heikki Linnakangas 提交于
Moving the installation of gp_toolkit.sql into initdb, in commit f8910c3c, broke all the functions that are supposed to execute on all nodes, like gp_toolkit.__gp_localid. After that change, gp_toolkit.sql was executed in utility mode, and the gp_distribution_policy entries for those functions were not created as a result. To fix, change the code so that gp_distribution_policy entries are never never created, or consulted, for EXECUTE-type external tables. They have more fine-grained information in pg_exttable.location field anyway, so rely on that instead. With this change, there is no difference in whether an EXECUTE-type external table is created in utility mode or not. We would still have similar problems if gp_toolkit contained other kinds of external tables, but it doesn't. This removes the isMasterOnly() function and changes all its callers to call GpPolicyFetch() directly instead. Some places used GpPolicyFetch() directly to check if a table is distributed, so this just makes that the canonical way to do it. The check for system schemas that used to be in isMasterOnly() are no longer performed, but they should've unnecessary in the first place. System tables don't have gp_distribution_policy entries, so they'll be treated as master-only even without that check.
-
- 08 1月, 2016 2 次提交
-
-
由 Daniel Gustafsson 提交于
Remove superflous ";" to ensure that the return value is set based on the success of udpSignalGet(). Verified by lchang@. This only affects OS X builds.
-
由 Ashwin Agrawal 提交于
-
- 07 1月, 2016 4 次提交
-
-
由 Heikki Linnakangas 提交于
These were both only used by a single, static, function.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
The real ones are in parse_expr.h and makefuncs.h.
-
由 Ashwin Agrawal 提交于
gpverify functionality was planned in past to deliver online verification of primary and mirror. It's completely dead code as never exposed this functionality and have no plans either. It eliminates creation of unused processes, extra directory, some shared memory and all.
-
- 05 1月, 2016 2 次提交
-
-
由 Daniel Gustafsson 提交于
This is from a quick read through/skim of the code and comments.
-
由 Daniel Gustafsson 提交于
-
- 23 12月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
This code and bug was in 1f4ad703, and it caused an "operator XXX is not a valid ordering operator" error. The 'sortop' field in SortClause and GroupClause needs to be an ordering operator, i.e. the "<" operator, while we use the "=" operator to represent grouping in other places. Need to be careful to convert between the two in right places. Add a few tests for this in the gp_dqa test case. This was reproducible by the existing queries, when you coerce the planner to choose sort+group aggregates instead of hash aggregates.
-
- 21 12月, 2015 2 次提交
-
-
由 George Caragea 提交于
-
由 Pengzhou Tang 提交于
SET command is session effective, all existed idle gangs should be set for later reuse, but for busy gangs declared by cursors, errors occur if they receive a set command. Way to fix it is marking busy gangs to no reuse so they can be destroyed after cursors been closed.
-
- 20 12月, 2015 1 次提交
-
-
由 Robert Mu 提交于
Heikki suggested that we backport atomic operation from PostgreSQL 9.5 to fix this commit b64d92f1 Author: Andres Freund <andres@anarazel.de> Date: Thu Sep 25 23:49:05 2014 +0200 Add a basic atomic ops API abstracting away platform/architecture details. Several upcoming performance/scalability improvements require atomic operations. This new API avoids the need to splatter compiler and architecture dependent code over all the locations employing atomic ops. For several of the potential usages it'd be problematic to maintain both, a atomics using implementation and one using spinlocks or similar. In all likelihood one of the implementations would not get tested regularly under concurrency. To avoid that scenario the new API provides a automatic fallback of atomic operations to spinlocks. All properties of atomic operations are maintained. This fallback - obviously - isn't as fast as just using atomic ops, but it's not bad either. For one of the future users the atomics ontop spinlocks implementation was actually slightly faster than the old purely spinlock using implementation. That's important because it reduces the fear of regressing older platforms when improving the scalability for new ones. The API, loosely modeled after the C11 atomics support, currently provides 'atomic flags' and 32 bit unsigned integers. If the platform efficiently supports atomic 64 bit unsigned integers those are also provided. To implement atomics support for a platform/architecture/compiler for a type of atomics 32bit compare and exchange needs to be implemented. If available and more efficient native support for flags, 32 bit atomic addition, and corresponding 64 bit operations may also be provided. Additional useful atomic operations are implemented generically ontop of these. The implementation for various versions of gcc, msvc and sun studio have been tested. Additional existing stub implementations for * Intel icc * HUPX acc * IBM xlc are included but have never been tested. These will likely require fixes based on buildfarm and user feedback. As atomic operations also require barriers for some operations the existing barrier support has been moved into the atomics code. Author: Andres Freund with contributions from Oskari Saarenmaa Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com, 20131015123303.GH5300@awork2.anarazel.de, 20131028205522.GI20248@awork2.anarazel.de
-
- 18 12月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
This bug was introduced in merge commit 1f4ad703, by a mishap in merging the upstream changes to convert_IN_to_join. The constructed InInfoClause entry was accidentally added to the list of in-clauses twice. That was usually harmless, but if the in-clause was later pulled up from a subquery, the code adjusts the varnos while merging the range tables of the subquery and its parent, ran twice. In doing so, it adjusted the varno twice, pointing it to wrong or non-existing range table entry.
-
- 09 12月, 2015 6 次提交
-
-
由 Heikki Linnakangas 提交于
Instead of creating a mock version of every backend object file, only create mock files as needed by individual tests. Speeds up the build, and is nicer anyway.
-
由 Heikki Linnakangas 提交于
This inverts the logic of the <testname>_REAL_OBJS mechanism. We now link with the real version of each object file, *except* those listed in <testname>_MOCK_OBJS variable.
-
由 Heikki Linnakangas 提交于
Some tests were already doing this, but it seems nicer to default to using the real memory manager for all tests. An individual test can still opt-out by listing the relevant files in <testname>_MOCK_OBJS. Some tests had had to jump through hoops to mock the memory manager, which is no longer necessary.
-
由 Heikki Linnakangas 提交于
There are a bunch of backend files that are never mocked, but always linked into test program as is. List those in Makefile.mock, so that every Makefile doesn't need to list them. Makes the makefiles simpler, and you need less boilerplate code when adding a new test program. Not all of these backend files were listed in the _REAL_OBJS variable of every test, but in those tests that they were not, they were also not used, so it doesn't matter if we use the real or mock version.
-
由 Heikki Linnakangas 提交于
This way we don't need to link the whole backend into client mock programs. We've gotten away with it so far, but it would cause clashes if one of the client programs contained a function or global variable with same name as in the backend. And of course it's completely unnecessary anyway.
-
由 Heikki Linnakangas 提交于
Seems cleaner.
-
- 04 12月, 2015 3 次提交
-
-
由 Heikki Linnakangas 提交于
They belong in headers. Otherwise, if the function's signature changes, the compiler will not warn you.
-
由 Heikki Linnakangas 提交于
Makes merging easier.
-
由 Heikki Linnakangas 提交于
It's no longer needed, as Params carry a typmod now.
-
- 03 12月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
This was causing a segfault when compiling with -O3 on Centos 7 (gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)). I'm not 100% if that was actually a compiler bug, but unaligned access would definitely be wrong on architectures that are strict on alignment anyway.
-
- 01 12月, 2015 1 次提交
-
-
由 Garrett Thornburg 提交于
This patch merges the PostgreSQL 9.5 implementation of SSE4.2 into GPDB. The SSE4.2 implementation was lifted right out of PostgreSQL without change to make merging later PostgreSQL releases easier. Update win32 configuration to support SSE4.2 runtime checks This change was pulled from "src/include/pg_config.h.win32" from the commits below. configure.in changes, determining if cpu instruction for perfomring runtime checks are availible, and moving some of the code to port SSE4.2 came from the following PostgreSQL commits: commit 3dc2d62d Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Date: Tue Apr 14 17:05:03 2015 +0300 Use Intel SSE 4.2 CRC instructions where available. Modern x86 and x86-64 processors with SSE 4.2 support have special instructions, crc32b and crc32q, for calculating CRC-32C. They greatly speed up CRC calculation. Whether the instructions can be used or not depends on the compiler and the target architecture. If generation of SSE 4.2 instructions is allowed for the target (-msse4.2 flag on gcc and clang), use them. If they are not allowed by default, but the compiler supports the -msse4.2 flag to enable them, compile just the CRC-32C function with -msse4.2 flag, and check at runtime whether the processor we're running on supports it. If it doesn't, fall back to the slicing-by-8 algorithm. (With the common defaults on current operating systems, the runtime-check variant is what you get in practice.) Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund. commit b4eb2d16 Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Date: Tue Apr 14 19:56:00 2015 +0300 On gcc and clang, the _mm_crc32_u8 and _mm_crc32_u64 intrinsics are not defined at all, when not building with -msse4.2. But on icc, they are. So we cannot assume that if those intrinsics are defined, we can always use them safely, we might still need the runtime check. To fix, check if the __SSE_4_2__ preprocessor symbol is defined. That's supposed to be defined only when the compiler is targeting a processor that has SSE 4.2 support. Per buildfarm members fulmar and okapi.
-
- 19 11月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
The current plan is to use something like pg_upgrade for future in-place upgrades. The gpupgrade mechanism will not scale to the kind of drastic catalog and other data directory layout changes that are coming as we merge with later PostgreSQL releases. Kept gpupgrademirror for now. Need to check if there's some logic that's worth saving, for a possible pg_upgrade based solution later.
-
- 18 11月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
It was just syntax and catalogs, you couldn't actually do anything useful with it. Remove it, so that we have less code to maintain, until it's time to merge this stuff from upstream again when we merge with PostgreSQL 8.4. It's probably easier to merge this back at that point than maintain this backported version in the meanwhile. Less effort now, until we reach that point, and once we get to the point in 8.4 that we merge this in, we'll have all the preceding patches applied already, so it should merge quite smoothly.
-
- 16 11月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
This makes merging and diffing with upstream easier. There were so many GPDB-added GUCs in guc.c that "git merge" didn't handle it very well, and you easily got merge conflicts that were error-prone to fix manually. I kept a few GUCs in guc.c that are not present in REL8_2_0, because they were backported from later PostgreSQL versions, rather than being completely GPDB-specific. Clean up the diff between guc.c and upstream, by removing unnecessary includes, reordering a few GUCs to match upstream better, and similar cosmetic changes. I had to move MAX_KILOBYTES from guc.c to guc_tables.h, because guc_gp.c needs it too. I also had to export assign_msglvl() function from guc.c, so that it can be called from other assign_* functions from guc_gp.c. And I had to add the code to process the ConfigureNames*_gp arrays in addition to the upstream ones. These things increase the diff against upstream, but not by too much, IMHO. I also copy-pasted constants like MS_PER_S and KB_PER_MB, which seems safe as those are natural constants, and should never change.
-
- 07 11月, 2015 1 次提交
-
-
由 Heikki Linnakangas 提交于
Now that we no longer forcibly compile strlcpy.c, and only compile and link it into strlcpy.o into libpgport when needed, this is no longer needed. Furthermore, it caused the linking to fail on platforms that don't need strlcpy.o, like OS X.
-
- 05 11月, 2015 1 次提交
-
-
由 Ashwin Agrawal 提交于
Relation can potential be dropped while waiting to acquire lock. If cannot find the relation for "if_exists" case should just emit NOTICE and act as noop.
-
- 28 10月, 2015 1 次提交
-
-