- 08 12月, 2018 6 次提交
-
-
由 Lisa Owen 提交于
-
由 Adam Berlin 提交于
-
由 Lisa Owen 提交于
* docs - foreign data wrapper sql and catalog re page updates * misc edits * clarify mpp_execute any value
-
由 Lisa Owen 提交于
* docs - remove operator RECHECK; add note, update sys catalog * add blank line
-
由 Chuck Litzell 提交于
-
由 Jimmy Yih 提交于
These are dead references. Just remove them as simple clean up. Co-authored-by: NJimmy Yih <jyih@pivotal.io> Co-authored-by: NBradford D. Boyle <bboyle@pivotal.io>
-
- 07 12月, 2018 34 次提交
-
-
由 David Yozie 提交于
-
由 Daniel Gustafsson 提交于
The referred to function is called try_relation_open() and nothing else. This typo was introduced in 2011 when CdbTryOpenRelation() was added so it seems about time to correct it.
-
由 Daniel Gustafsson 提交于
get_str_from_chunk() is using normal memory management and bypassing the PostgreSQL memory manager. This means that allocations aren't automatically guarded by the backend, and it was failing to correctly check if allocations were successful thus risking a NULL pointer dereference. Return NULL on out of memory error since there is little else we can do, and the caller can handle it without dereferencing NULL.
-
由 Daniel Gustafsson 提交于
The support for sending alerts via Email or SNMP was quite a kludge, and there are much better external tools for managing alerts than what we can supply in core anyways so this retires the capability. All references to alert sending in the docs are removed, but there needs to be section written about how to migrate off this feature in the release notes or a similar location. Discussion: https://github.com/greenplum-db/gpdb/pull/6384
-
由 Heikki Linnakangas 提交于
Extract the first key column's Datum only once, to avoid the memtuple_getattr / heap_getattr overhead. This is the same optimization we have in tuplesort.c. Reviewed-by: NPengzhou Tang <ptang@pivotal.io> Reviewed-by: NGang Xiong <gxiong@pivotal.io>
-
由 Heikki Linnakangas 提交于
Avoid palloc+memcpy for "TC_WHOLE" tuples. Reviewed-by: NPengzhou Tang <ptang@pivotal.io> Reviewed-by: NGang Xiong <gxiong@pivotal.io>
-
由 Heikki Linnakangas 提交于
More modern, and faster too. Reviewed-by: NPengzhou Tang <ptang@pivotal.io> Reviewed-by: NGang Xiong <gxiong@pivotal.io>
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
Htupfifo is used when parsing incoming messages from the interconnect. Each UDP message consists of a number of tuple chunks, which form a number of tuples. When one incoming message is parsed, the htupfifo is used to hold the tuples formed from the single message. Typically, each message contains roughly the same number of tuples, so it is wasteful to palloc/pfree the list node for every tuple. That's why there is a free list in the FIFO. However, with narrow tuples, one message can contain hundreds of tuples, which is much more than the built-in max size on the free list size (10). So in practice, the free list was almost never enough to cover the need. The message size puts a natural limit on how large the FIFO can grow, so I don't think we need a limit on the free list size. Just let it grow as large as needed, and avoid the palloc/pfree overhead. Reviewed-by: NPengzhou Tang <ptang@pivotal.io> Reviewed-by: NGang Xiong <gxiong@pivotal.io>
-
由 Heikki Linnakangas 提交于
It was dead code, and we have no plans to resurrect it. Reviewed-by: NPengzhou Tang <ptang@pivotal.io> Reviewed-by: NGang Xiong <gxiong@pivotal.io>
-
由 Heikki Linnakangas 提交于
The non-MK code was abusing the child's result tuple slot. The corresponding MK code was changed back in 2010 to not do that, but that commit missed the non-MK version. This caused a segfault in the 'subselect' regression test. Apparently no one has run the regression tests with 'gp_enable_motion_mk_sort=off' recently. Reviewed-by: NPengzhou Tang <ptang@pivotal.io> Reviewed-by: NGang Xiong <gxiong@pivotal.io>
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
The 9.1 merge removed the code that incremented 'num_consec_csv_err'. Since then, it was only ever initialized to 0. Hence, all the related code was dead. I'm not sure how we behave with the kinds of errors that used to trigger this code now. But I don't see a need to treat them specially, the generic error handling code should cope with them. The GUC that controlled the max CSV line length was removed in commit 6ac29fdc already.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
They were only used to pass the information to cdbCopyStart(). Better to pass them directly as arguments.
-
由 Heikki Linnakangas 提交于
Simpler to just pick a constant starting size. It's probably faster, too, to let the hash table expand as needed, than work hard upfront to make a good guess.
-
由 Heikki Linnakangas 提交于
-
由 Ning Yu 提交于
The following WARNING is generated by ANALYZE when some sample tuples are from segments outside the [0, numsegments-1] range, however this does not indicate the data distribution is wrong. Take inherited tables for example, when inherited tables has greater numsegments than parent this WARNING will be raised, and it is expected. This could happen normally on the random_numsegments pipeline job, so ignore this WARNING. WARNING: table "patest0" contains rows in segment 2, which is outside the # of segments for the table's policy (2 segments) Added this pattern to init_file to ignore it.
-
由 Ning Yu 提交于
It was placed under JOIN group but as it is a regression test moved it to REGRESSION group.
-
由 Ning Yu 提交于
This new pipeline job run ICG tests, all the tables are created with random numsegments, the purpose is to improve test coverage on MxN queries. Some tests are disabled because their behavior and/or output depend on data distribution, in general could be grouped as below: - checks gp_segment_id; - contains EXCHANGE PARTITION, which require the two tables have the same numsegments; - turns on `test_print_direct_dispatch_info`, the output depends on numsegments; Some tests can pass by adding some enforcement or alignments on numsegments, but we do not want to include such kind of hacks on those tests for now. Some tests can be re-enabled later if we can make them stable without changing them.
-
由 Ning Yu 提交于
CREATE TABLE always set numsegments to DEFAULT, however when there is a DISTRIBUTED BY clause it might already contain a valid numsegments. This will not happen in a user typed CREATE TABLE sql because there is no syntax to specify numsegments, so far the only chance for this to happen is the internal command constructed by reorganization, it might be a CTAS or (CREATE + INSERT), both will pass original numsegments via DISTRIBUTED BY. One bug is that we only accept numsegments passed by CTAS but not the other. The (CREATE + INSERT) command is only constructed in 3 cases: 1. original table contains dropped column(s); 2. original table is AOCO; 3. original table is AO with index(es); Fixed and added tests.
-
由 Ning Yu 提交于
When creating a partition table we want children have the same numsegments with parent. As they all set their numsegments to DEFAULT, does this meet our expectation? No, because DEFAULT does not always equal to DEFAULT itself. When DEFAULT is set to RANDOM a different value is returned each time. So we have to align numsegments explicitly. Also removed an incorrect assert and comment.
-
由 Daniel Gustafsson 提交于
The pass statement is a no-op intended to be used in empty classes or other types of stubs. When following other statements in a block it has no purpose. Remove all such occurrences. Reviewed-by: NJacob Champion <pchampion@pivotal.io>
-
由 Adam Berlin 提交于
-
由 Daniel Gustafsson 提交于
The dump_tmc() function is just a shorthand for running dump_mc() on the TopMemoryContext. Since dumping MemoryContexts has no call- sites in the code and is only available in a debugger, it seems a bit rich to spend object file space for saving a few keystrokes in GDB. This removes dump_tmc() in favour of just using dump_mc(). Reviewed-by: NHeikki Linnakangas <hlinnakangas@pivotal.io> Reviewed-by: NAshwin Agrawal <aagrawal@pivotal.io>
-
由 Daniel Gustafsson 提交于
The SwitchedMemoryContext is not an actual new context type, but merely a set of convenience functions for wrapping allocation and switching into a single call. This was only used at two callsites, and cause pointless merge conflicts with upstream (not to mention making code reading harder since it's a new concept from what we're all used to). This removes and replaces with normal memory context calls. Reviewed-by: NHeikki Linnakangas <hlinnakangas@pivotal.io> Reviewed-by: NAshwin Agrawal <aagrawal@pivotal.io>
-
由 Daniel Gustafsson 提交于
The floor_log2_Size() and ceil_log2_Size() functions were used by the old malloc() based abstract memory context which was removed in the 5.x cycle. They are now unused so remove. Reviewed-by: NHeikki Linnakangas <hlinnakangas@pivotal.io> Reviewed-by: NAshwin Agrawal <aagrawal@pivotal.io>
-
由 Jacob Champion 提交于
For 8-byte-long platforms, strtoul() is fine. Otherwise we try to use strtoull(), and then fail to compile if that doesn't exist. Co-authored-by: NJim Doty <jdoty@pivotal.io>
-
由 Jacob Champion 提交于
Per suggestion from Daniel. Co-authored-by: NJim Doty <jdoty@pivotal.io>
-
由 Jacob Champion 提交于
The copied system identifiers from the master need to be made unique so that mirrors cannot accidently connect to the wrong primaries. We do this with the --system-identifier option to pg_resetxlog introduced in the last commit. We have also added a test to verify unique system identifiers are assigned to the segments. Co-authored-by: NShoaib Lari <slari@pivotal.io> Co-authored-by: NJim Doty <jdoty@pivotal.io>
-
由 Jacob Champion 提交于
For upgrade, we need to reset the database system identifier in the pg_control file for the segments. The --system-identifier option lets us do that. Per Daniel's suggestion, move all GPDB-specific additions to use long options; the -y option is now --binary-upgrade. We've based the new long-options machinery on e22b27f0 from upstream, which adds long options to pg_resetwal. This should make it easier to merge later. Co-authored-by: NJim Doty <jdoty@pivotal.io> Co-authored-by: NShoaib Lari <slari@pivotal.io>
-
由 Abhijit Subramanya 提交于
-
由 Jesse Zhang 提交于
Given a database in which the "public" schema does not have its default OID 2200 (e.g. it was dropped and recreated), pg_upgrade would ignore the previous OID and use the built-in "public" schema at restoration. This is because creation of the "public" schema is skipped in dump / restore. Add a binary_upgrade field to RestoreOptions, to teach pg_dump / pg_restore not to skip the public schema during binary upgrade. This adds a new "--binary-upgrade" option to pg_restore. Co-authored-by: NJacob Champion <pchampion@pivotal.io> Co-authored-by: NJesse Zhang <sbjesse@gmail.com>
-