1. 16 Oct, 2019 3 commits
  2. 15 Oct, 2019 1 commit
    • Andres Freund's avatar
      Fix CLUSTER on expression indexes. · cef82eda
      Andres Freund authored
      Since the introduction of different slot types, in 1a0586de, we
      create a virtual slot in tuplesort_begin_cluster(). While that looks
      right, it unfortunately doesn't actually work, as ExecStoreHeapTuple()
      is used to store tuples in the slot. Unfortunately no regression tests
      for CLUSTER on expression indexes existed so far.
      
      Fix the slot type, and add bare bones tests for CLUSTER on expression
      indexes.
      
      Reported-By: Justin Pryzby
      Author: Andres Freund
      Discussion: https://postgr.es/m/20191011210320.GS10470@telsasoft.com
      Backpatch: 12, like 1a0586de
      cef82eda
  3. 14 Oct, 2019 2 commits
    • Tomas Vondra's avatar
      Correct reference to pg_catalog.regtype in pg_upgrade query · 3a0e8573
      Tomas Vondra authored
      The recursive CTE added in 0ccfc282 referenced pg_catalog.regtype,
      without the schema part, unlike all other queries in pg_upgrade.
      
      Backpatch-to: 12
      3a0e8573
    • Tomas Vondra's avatar
      Check for tables with sql_identifier during pg_upgrade · 0ccfc282
      Tomas Vondra authored
      Commit 7c15cef8 changed sql_identifier data type to be based on name
      instead of varchar.  Unfortunately, this breaks on-disk format for this
      data type.  Luckily, that should be a very rare problem, as this data
      type is used only in information_schema views, so this only affects user
      objects (tables, materialized views and indexes).  One way to end in
      such situation is to do CTAS with a query on those system views.
      
      There are two options to deal with this - we can either abort pg_upgrade
      if there are user objects with sql_identifier columns in pg_upgrade, or
      we could replace the sql_identifier type with varchar.  Considering how
      rare the issue is expected to be, and the complexity of replacing the
      data type (e.g. in matviews), we've decided to go with the simple check.
      
      The query is somewhat complex - the sql_identifier data type may be used
      indirectly - through a domain, a composite type or both, possibly in
      multiple levels.  Detecting this requires a recursive CTE.
      
      Backpatch to 12, where the sql_identifier definition changed.
      
      Reported-by: Hans Buschmann
      Author: Tomas Vondra
      Reviewed-by: Tom Lane
      Backpatch-to: 12
      Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org
      0ccfc282
  4. 13 Oct, 2019 5 commits
    • Michael Paquier's avatar
      Update test output of sepgsql for ALTER TABLE COLUMN DROP · 14ac4237
      Michael Paquier authored
      1df5875d has changed the way dependencies are dropped for this command
      with inheritance trees, which impacts sepgsql.  This just updates the
      regression test output to take care of the failures and adapt to the new
      code.
      
      Reported by buildfarm member rhinoceros.
      
      Author: Michael Paquier
      Reviewed-by: Tom Lane
      Discussion: https://postgr.es/m/20191013101331.GC1434@paquier.xyz
      Backpatch-through: 12
      14ac4237
    • Peter Eisentraut's avatar
      Update unicode.org URLs · bdb839cb
      Peter Eisentraut authored
      Use https, consistent host name, remove references to ftp.  Also
      update the URLs for CLDR, which has moved from Trac to GitHub.
      bdb839cb
    • Tom Lane's avatar
      In the postmaster, rely on the signal infrastructure to block signals. · 9abb2bfc
      Tom Lane authored
      POSIX sigaction(2) can be told to block a set of signals while a
      signal handler executes.  Make use of that instead of manually
      blocking and unblocking signals in the postmaster's signal handlers.
      This should save a few cycles, and it also prevents recursive
      invocation of signal handlers when many signals arrive in close
      succession.  We have seen buildfarm failures that seem to be due to
      postmaster stack overflow caused by such recursion (exacerbated by
      a Linux PPC64 kernel bug).
      
      This doesn't change anything about the way that it works on Windows.
      Somebody might consider adjusting port/win32/signal.c to let it work
      similarly, but I'm not in a position to do that.
      
      For the moment, just apply to HEAD.  Possibly we should consider
      back-patching this, but it'd be good to let it age awhile first.
      
      Discussion: https://postgr.es/m/14878.1570820201@sss.pgh.pa.us
      9abb2bfc
    • Tom Lane's avatar
      Revert "Hack pg_ctl to report postmaster's exit status." · f38291e9
      Tom Lane authored
      This reverts commit 6a5084ee.
      We learned what we needed to know from that.
      f38291e9
    • Michael Paquier's avatar
      Fix dependency handling of column drop with partitioned tables · 1df5875d
      Michael Paquier authored
      When dropping a column on a partitioned table which has one or more
      partitioned indexes, the operation was failing as dependencies with
      partitioned indexes using the column dropped were not getting removed in
      a way consistent with the columns involved across all the relations part
      of an inheritance tree.
      
      This commit refactors the code executing column drop so as all the
      columns from an inheritance tree to remove are gathered first, and
      dropped all at the end.  This way, we let the dependency machinery sort
      out by itself the deletion of all the columns with the partitioned
      indexes across a partition tree.
      
      This issue has been introduced by 1d92a0c9, so backpatch down to
      REL_12_STABLE.
      
      Author: Amit Langote, Michael Paquier
      Reviewed-by: Álvaro Herrera, Ashutosh Sharma
      Discussion: https://postgr.es/m/CA+HiwqE9kuBsZ3b5pob2-cvE8ofzPWs-og+g8bKKGnu6b4-yTQ@mail.gmail.com
      Backpatch-through: 12
      1df5875d
  5. 12 Oct, 2019 2 commits
  6. 11 Oct, 2019 1 commit
  7. 10 Oct, 2019 3 commits
  8. 09 Oct, 2019 5 commits
  9. 08 Oct, 2019 4 commits
  10. 07 Oct, 2019 9 commits
  11. 06 Oct, 2019 2 commits
    • Tom Lane's avatar
      Doc: improve docs about pg_statistic_ext_data. · 732457b5
      Tom Lane authored
      Commit aa087ec6 was a bit over-hasty about the doc changes needed
      while splitting pg_statistic_ext_data off from pg_statistic_ext.
      It duplicated one para and inserted another in what seems to me
      to be the wrong section.  Fix that up, and in passing do some minor
      copy-editing.
      
      Per report from noborusai.
      
      Discussion: https://postgr.es/m/CAAM3qnLXLUz4mOBkqa8jxigpKhKNxzSuvwpjvCRPvO5EqWjxSg@mail.gmail.com
      732457b5
    • Tom Lane's avatar
      Avoid trying to release a List's initial allocation via repalloc(). · ac12ab06
      Tom Lane authored
      Commit 1cff1b95 included some code that supposed it could repalloc()
      a memory chunk to a smaller size without risk of the chunk moving.
      That was not a great idea, because it depended on undocumented behavior
      of AllocSetRealloc, which commit c477f3e4 changed thereby breaking it.
      (Not to mention that this code ought to work with other memory context
      types, which might not work the same...)  So get rid of the repalloc
      calls, and instead just wipe the now-unused ListCell array and/or tell
      Valgrind it's NOACCESS, as if we'd freed it.
      
      In cases where the initial list allocation had been quite large, this
      could represent an annoying waste of space.  In principle we could
      ameliorate that by allocating the initial cell array separately when
      it exceeds some threshold.  But that would complicate new_list() which
      is hot code, and the returns would materialize only in narrow cases.
      On balance I don't think it'd be worth it.
      
      Discussion: https://postgr.es/m/17059.1570208426@sss.pgh.pa.us
      ac12ab06
  12. 05 Oct, 2019 3 commits