Skip to content

G
Gpdb

Greenplum / Gpdb

通知 7
Star 1
Fork 0
G
Gpdb

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 14 8月, 2019 1 次提交
  3. 13 8月, 2019 3 次提交
  5. 12 8月, 2019 12 次提交
    • D
      Check for --with-libcurl in gpcloud configuration · 6bbdff3b
      由 Daniel Gustafsson 提交于 
      libcurl is required by gpcloud, but there was no explicit dependency
on it in autoconf which would cause compiler errors in a build with
gpcloud but without libcurl. Fix by adding a similar dependencycheck
that we have for PXF.
Reviewed-by: NLav Jain <ljain@pivotal.io>
Reviewed-by: NJimmy Yih <jyih@pivotal.io>
      6bbdff3b
    • A
      Run deadlock_under_entry_db_singleton by itself · d160d5c1
      由 Asim R P 提交于 
      The test injects a fault in StartTransaction().  This function is so
generic that any concurrent test may trigger the fault, leading to
failed or misleading outcome.  The test was using old faultinjector,
which emitted status of a fault as NOTICE message.  NOTICE messages do
not appear in isolation2 answer files.  So this problem went
undetected.
      d160d5c1
    • A
      Do not expect warning to disable FTS for panic type fault · a6599e22
      由 Asim R P 提交于 
      The intention behind the warning was to guide the test writer to avoid
flaky behavior due to FTS intervening in the middle of a PANIC to mark
a segment as down.

This is good, however, the way the warning is emitted is not correct.
The underlying assumption in the warning implementation (see
fbd0f091) is that InjectFault() function is executed by the same
process that created the gp_inject_fault extension.  This is not valid
in the new libpq based fault injector because the fault is injected by
a transient fault handler process, which is always different from the
process that creates the extension when running regression tests.

Evidently, there are several tests injecting 'panic' type fault
already and their answer files don't have such warnings.  The
bitmap_index test modified by this commit was the only test still
using old fault injector interface to inject a 'panic' fault.  In the
old fault injector, the above mentioned assumption was applicable and
the warning was emitted.  Now that we've moved to new implementation
wholesale, the warning must be removed.

We should go back to drawing board for emitting the FTS warning but
that's a separate patch.
      a6599e22
    • A
      Update answer files according to the new fault injector API · 748f86fb
      由 Asim R P 提交于 
      Remove NOTICE messages that follow a gp_inject_fault() select statement.
Replace the boolean value with text 'Success:' returned by the new
interfae.

For reference, the following sed script was used to identify 't'
following a ' gp_inject_fault ' line:

/^ gp_inject_fault $/{
   $!{ N
       :again1
       N
       s/ t$/ Success:/
       t again1
     }
   }
      748f86fb
    • A
      Update tests that were using gp_inject_fault2 · 590ac108
      由 Asim R P 提交于 
      These tests were invoking the new fault injector interface using its
temporary name - gp_inject_fault2().  Now the new interface is the
only one present in the repository, named as gp_inject_fault().
      590ac108
    • A
      Replace old fault injector interface with the new one. · 83c336ad
      由 Asim R P 提交于 
      The new interface employs a special libpq connection parameter and a
libpq message to convey fault details to destination postmaster.  This
interface has been in use for some time now.  It was getting cumbersome
to maintain both the old as well as the new interface.

To be clear, we now have only one interface to inject fault and that is
"gp_inject_fault()".

Existing tests that were using gp_inject_fault2() will be updated in a
follow up commit.
      83c336ad
    • A
      gp_inject_fault2: obtain hostname and port from catalog · 41779acc
      由 Asim R P 提交于 
      This makes the signature of the new interface match that of the old
gp_inject_fault interface, so as to make it easy to replace the old interface
with the new one.
      41779acc
    • D
      Add more aliases to the mailmap · 03cd8713
      由 Daniel Gustafsson 提交于 
      Re-ran the script with a small tweak which generated two more hits,
soon we should be caught up with all variations we have.
      03cd8713
    • W
      Init plan with input param follow upstream execution flow · f6f1f9bb
      由 Weinan WANG 提交于 
      gpdb, we pre-execute init plan in ExecutorStart to reduce slice number.
However, for some initplans, which require params from the same level node,
should follow upstream execution flow.

To recognize this initplan's pattern, record `extParam` when creating
`subplan` object.

Fix issue: #6953
      f6f1f9bb
    • X
      Correct memory unit · c8ac4643
      由 xiong-gang 提交于 
      ExecChooseHashTableSize takes KB as parameter while global_work_mem returns bytes
      c8ac4643
    • Z
      Do not optimize select statement with locking clause when ORCA is enabled · 0e118441
      由 Zhenghua Lyu 提交于 
      Currently, ORCA does not emit LockRows plannode. So when
ORCA is enabled, we do not consider the query a simple
select-for-locking case.
      0e118441
    • A
      Print more details when a behave test fails · 2237ef21
      由 Asim R P 提交于 
      If a test decides to fail because not all segments are running, it will
be nice to get the details of segments that are found to be not running.

The details printed by this patch will only be shown by behave upon a test
failure.  They will not be shown when a test passes.
Reviewed-by: NGeorgios Kokolatos <gkokolatos@pivotal.io>
Reviewed-by: NJacob Champion <pchampion@pivotal.io>
Reviewed-by: NDavid Krieger <dkrieger@pivotal.io>
      2237ef21
  7. 10 8月, 2019 3 次提交
  9. 09 8月, 2019 1 次提交
  11. 08 8月, 2019 2 次提交
    • A
      Ensure the current probe does not cause flake · 38dd2da3
      由 Adam Berlin 提交于 
      Wait until we've inserted the fts_probe skip fault, AND we have
observed the fault being hit. This ensures that we've completed the
in-progress fts probe before continuing on with a test.

Previously, if we don't wait and our test continues forward to inject
a panic, then then in-progress fts probe would do its job and promote
the mirror.

We lower the minimum allowed gp_fts_probe_interval to 1 second, which
allows us to configure the interval to one second during our tests and
speeds up the tests significantly.
Reported-by: NAsim R P <apraveen@pivotal.io>
      38dd2da3
    • A
      Make sure externalgettup_custom() doesn't reach an unexpected state · 9b067ff0
      由 Adam Lee 提交于 
      pstate->raw_buf_len should never be less than zero because it's the
length of unprocessed data in externalgettup_custom(). Add an assert to
make sure this.
      9b067ff0
  13. 07 8月, 2019 4 次提交
  15. 06 8月, 2019 4 次提交
  17. 05 8月, 2019 4 次提交
    • A
      Fix more flakey gp_tablespace_with_faults tests. · fa64cc90
      由 Adam Berlin 提交于 
      The drop tablespace tests that introduce panics were not disabling
fts, which is a source of flakey tests.

Introduce a disable_fts() function that we can call before each
test. The fault reset at the end of each test will reenable fts for
the next test.
      fa64cc90
    • D
      Assorted gpMgmt/bin Makefile fixups · 9f707e1e
      由 Daniel Gustafsson 提交于 
      The tree I was working off clearly had stale files, which led me to
include two utils which were removed some time ago: gpcheckutil.py
and gpcheck.py. Remove these two from their respective Makefiles.

Also fix a Bash error in the Stream symlink test, the logoical AND
requires [[ .. ]]; rather than [ .. ];.

Both of these spotted while repeatedly running make install with
trees in various states.
      9f707e1e
    • W
      Fix `Explain Analyze` crash · 18f904a7
      由 Weinan WANG 提交于 
      We have a kind of query that its InitPlan execute in ExecutorStart.
If Explain Analyze this kind of query, as well as, some memory or disk
information requires to collect in the main plan, the QD will crash.
Since queryDesc->showstatctx->stats_gathered is assigned to true
in ExecSetParamPlan function before ExecutorRun, So we only gather
Initplan metrics and left other slices information over. Segment fault when
some execution node print out metrics message.

To fix this problem, variable stats_gathered only be assigned after slice 0
metrics information collection.

reproduce process:

create table t(a int);
explain analyze select a
from (
	select a
	from t
	where a > (
		select avg(a)
		from t
	)
) as foo
order by a
limit 1
fix issue:#6951
      18f904a7
    • T
      Fix typo in Docker documentation · 83eddecb
      由 The Alchemist 提交于 
      Reviewed-by: NDaniel Gustafsson <dgustafsson@pivotal.io>
      83eddecb
  19. 03 8月, 2019 6 次提交