1. 03 5月, 2019 2 次提交
  2. 19 4月, 2019 1 次提交
    • A
      Bump ORCA version to 3.35.0 · 034ec45c
      Ashuka Xue 提交于
      This corresponds to ORCA commit "Predicate pushdown in part tables with window func"
      It includes ICG changes
      034ec45c
  3. 18 4月, 2019 1 次提交
    • A
      Remove the --enable-testutils config option and code. · 1f9c430f
      Ashwin Agrawal 提交于
      Compilation with --enable-testutils seems to has been broken long time
      as `MaxDynamicLWLock` is no more defined. Given no one complained
      seems this is unused config option and code. Hence, instead of fixing
      the compilation ripping out this code.
      1f9c430f
  4. 13 4月, 2019 1 次提交
  5. 10 4月, 2019 1 次提交
  6. 29 3月, 2019 1 次提交
  7. 28 3月, 2019 1 次提交
  8. 21 3月, 2019 1 次提交
  9. 19 3月, 2019 1 次提交
  10. 16 3月, 2019 1 次提交
  11. 13 3月, 2019 1 次提交
    • T
      Build necessary extensions for release (#7057) · 35a71407
      Tingfang Bao 提交于
      * Build necessary extensions for release
      
      * Add new  '--enable-debug-extensions' configure option, if provide the option,
        the extensions include:
      
            gp_distribution_policy
            gp_internal_tools
            gp_sparse_vector
            gp_replica_check
            gp_inject_fault
            gp_debug_numsegments
      
      * Rename configure_flags to configure_flags_with_extensions
      
        The configure_flags_with_extensions SHOULD BE set to
      
            configure_flags_with_extensions: "--enable-cassert --enable-debug-extensions"
      
          in these secrets files
      
             secrets/gpdb_master-ci-secrets.dev.yml
             secrets/gpdb_master-ci-secrets.prod.yml
      Co-authored-by: NBob Bao <bbao@pivotal.io>
      Co-authored-by: NNing Fu <nfu@pivotal.io>
      35a71407
  12. 12 3月, 2019 1 次提交
  13. 27 2月, 2019 1 次提交
  14. 16 2月, 2019 1 次提交
  15. 13 2月, 2019 2 次提交
  16. 12 2月, 2019 3 次提交
  17. 09 2月, 2019 1 次提交
  18. 05 2月, 2019 1 次提交
    • F
      Remove gphdfs from source code · ad6b920f
      Francisco Guerrero 提交于
      gphdfs is being deprecated for GPDB 6. This commit removes the
      following:
      - Remove gphdfs from pipelines
      - Remove gphdfs from gpcontrib
      - Remove gphdfs from Makefile
      - Remove tests using gphdfs
      - Remove GUCs, code, and comments used for gphdfs
      - Remove gphdfs from GPDB docs
      - Remove avro and parquet formats
      ad6b920f
  19. 31 1月, 2019 1 次提交
  20. 24 1月, 2019 1 次提交
    • J
      Prevent int128 from requiring more than MAXALIGN alignment. · d74dd56a
      Jesse Zhang 提交于
      We backported 128-bit integer support to speed up aggregates (commits
      8122e143 and 959277a4) from upstream 9.6 into Greenplum (in
      commits 9b164486 and 325e6fcd). However, we forgot to also port a
      follow-up fix postgres/postgres@7518049980b, mostly because it's nuanced
      and hard to reproduce.
      
      There are two ways to tell the brokenness:
      
      1. On a lucky day, tests would fail on my workstation, but not my laptop (or
         vice versa).
      
      1. If you stare at the generated code for `int8_avg_combine` (and friends),
         you'll notice the compiler uses "aligned" instructions like `movaps` and
         `movdqa` (on AMD64).
      
      Today's my lucky day.
      
      Original commit message from postgres/postgres@7518049980b (by Tom Lane):
      
      > Our initial work with int128 neglected alignment considerations, an
      > oversight that came back to bite us in bug #14897 from Vincent Lachenal.
      > It is unsurprising that int128 might have a 16-byte alignment requirement;
      > what's slightly more surprising is that even notoriously lax Intel chips
      > sometimes enforce that.
      
      > Raising MAXALIGN seems out of the question: the costs in wasted disk and
      > memory space would be significant, and there would also be an on-disk
      > compatibility break.  Nor does it seem very practical to try to allow some
      > data structures to have more-than-MAXALIGN alignment requirement, as we'd
      > have to push knowledge of that throughout various code that copies data
      > structures around.
      
      > The only way out of the box is to make type int128 conform to the system's
      > alignment assumptions.  Fortunately, gcc supports that via its
      > __attribute__(aligned()) pragma; and since we don't currently support
      > int128 on non-gcc-workalike compilers, we shouldn't be losing any platform
      > support this way.
      
      > Although we could have just done pg_attribute_aligned(MAXIMUM_ALIGNOF) and
      > called it a day, I did a little bit of extra work to make the code more
      > portable than that: it will also support int128 on compilers without
      > __attribute__(aligned()), if the native alignment of their 128-bit-int
      > type is no more than that of int64.
      
      > Add a regression test case that exercises the one known instance of the
      > problem, in parallel aggregation over a bigint column.
      
      > This will need to be back-patched, along with the preparatory commit
      > 91aec93e.  But let's see what the buildfarm makes of it first.
      
      > Discussion: https://postgr.es/m/20171110185747.31519.28038@wrigleys.postgresql.org
      
      (cherry picked from commit 75180499)
      d74dd56a
  21. 19 1月, 2019 2 次提交
  22. 18 1月, 2019 1 次提交
  23. 15 1月, 2019 2 次提交
  24. 12 1月, 2019 1 次提交
  25. 11 1月, 2019 1 次提交
  26. 27 12月, 2018 1 次提交
  27. 18 12月, 2018 1 次提交
  28. 15 12月, 2018 1 次提交
  29. 14 12月, 2018 1 次提交
  30. 11 12月, 2018 1 次提交
  31. 07 12月, 2018 2 次提交
  32. 06 12月, 2018 1 次提交
  33. 05 12月, 2018 1 次提交