Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 17 Oct, 2019 3 commits
  3. 16 Oct, 2019 9 commits
    • Thomas Munro's avatar
      Fix bug that could try to freeze running multixacts. · 6bda2af0
      Thomas Munro authored 
      Commits 801c2dc7 and 801c2dc7 made it possible for vacuum to
try to freeze a multixact that is still running.  That was
prevented by a check, but raised an error.  Repair.

Back-patch all the way.

Author: Nathan Bossart, Jeremy Schneider
Reported-by: Jeremy Schneider
Reviewed-by: Jim Nasby, Thomas Munro
Discussion: https://postgr.es/m/DAFB8AFF-2F05-4E33-AD7F-FF8B0F760C17%40amazon.com
      6bda2af0
    • Alvaro Herrera's avatar
      Fix crash when reporting CREATE INDEX progress · 0d21f919
      Alvaro Herrera authored 
      A race condition can make us try to dereference a NULL pointer to the
PGPROC struct of a process that's already finished.  That results in
crashes during REINDEX CONCURRENTLY and CREATE INDEX CONCURRENTLY.

This was introduced in ab0dfc96, so backpatch to pg12.

Reported by: Justin Pryzby
Reviewed-by: Michaël Paquier
Discussion: https://postgr.es/m/20191012004446.GT10470@telsasoft.com
      0d21f919
    • Tomas Vondra's avatar
      Improve the check for pg_catalog.unknown data type in pg_upgrade · a524f50d
      Tomas Vondra authored 
      The pg_upgrade check for pg_catalog.unknown type when upgrading from 9.6
had a couple of issues with domains and composite types - it detected
even composite types unused in objects with storage. So for example this
was enough to trigger an unnecessary pg_upgrade failure:

  CREATE TYPE unknown_composite AS (u pg_catalog.unknown)

On the other hand, this only happened with composite types directly on
the pg_catalog.unknown data type, but not with a domain. So this was not
detected

  CREATE DOMAIN unknown_domain AS pg_catalog.unknown;
  CREATE TYPE unknown_composite_2 AS (u unknown_domain);

unlike the first example. These false positives and inconsistencies are
unfortunate, but what's worse we've failed to detected objects using the
pg_catalog.unknown type through a domain. So we missed cases like this

  CREATE TABLE t (u unknown_composite_2);

The consequence is clusters broken after a pg_upgrade.

This fixes these false positives and false negatives by using the same
recursive CTE introduced by eaf900e842 for sql_identifier. Backpatch all
the way to 10, where the of pg_catalog.unknown data type was restricted.

Author: Tomas Vondra
Backpatch-to: 10-
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org
      a524f50d
    • Tomas Vondra's avatar
      Improve the check for pg_catalog.line data type in pg_upgrade · 8d48e6a7
      Tomas Vondra authored 
      The pg_upgrade check for pg_catalog.line data type when upgrading from
9.3 had a couple of issues with domains and composite types. Firstly, it
triggered false positives for composite types unused in objects with
storage. This was enough to trigger an unnecessary pg_upgrade failure:

  CREATE TYPE line_composite AS (l pg_catalog.line)

On the other hand, this only happened with composite types directly on
the pg_catalog.line data type, but not with a domain. So this was not
detected

  CREATE DOMAIN line_domain AS pg_catalog.line;
  CREATE TYPE line_composite_2 AS (l line_domain);

unlike the first example. These false positives and inconsistencies are
unfortunate, but what's worse we've failed to detected objects using the
pg_catalog.line data type through a domain. So we missed cases like this

  CREATE TABLE t (l line_composite_2);

The consequence is clusters broken after a pg_upgrade.

This fixes these false positives and false negatives by using the same
recursive CTE introduced by eaf900e842 for sql_identifier. 9.3 did not
support domains on composite types, but we can still have multi-level
composite types.

Backpatch all the way to 9.4, where the format for pg_catalog.line data
type changed.

Author: Tomas Vondra
Backpatch-to: 9.4-
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org
      8d48e6a7
    • Andres Freund's avatar
      Replace alter_table.sql test usage of event triggers. · ae5cae54
      Andres Freund authored 
      The test in 93765bd9 added an event trigger to ensure that the
tested table rewrites do not get optimized away (as happened in the
past). But doing so would require running the tests in isolation, as
otherwise the trigger might also fire in concurrent sessions, causing
test failures there.

Reported-By: Tom Lane
Discussion: https://postgr.es/m/3328.1570740683@sss.pgh.pa.us
Backpatch: 12, just as 93765bd9
      ae5cae54
    • Michael Paquier's avatar
      Refresh some incorrect links in pg_crc.c/h · 1de4fd10
      Michael Paquier authored 
      Author: Vignesh C
Discussion: https://postgr.es/m/CALDaNm0LPk9vTGTBPBRv0=fX=94o4r6-DuBbHNeCN2AH5bufLw@mail.gmail.com
      1de4fd10
    • Thomas Munro's avatar
      Remove obsolete collation test. · cce95a2f
      Thomas Munro authored 
      The previous commit forgot to remove this test, which no longer
holds on all systems.
      cce95a2f
    • Thomas Munro's avatar
      Use libc version as a collation version on glibc systems. · d5ac14f9
      Thomas Munro authored 
      Using glibc's version string to detect potential collation definition
changes is not 100% reliable, but it's better than nothing.  Currently
this affects only collations explicitly provided by "libc".  More work
will be needed to handle the default collation.

Author: Thomas Munro, based on a suggestion from Christoph Berg
Reviewed-by: Peter Eisentraut
Discussion: https://postgr.es/m/4b76c6d4-ae5e-0dc6-7d0d-b5c796a07e34%402ndquadrant.com
      d5ac14f9
    • Michael Paquier's avatar
      Doc: Fix various inconsistencies · 4351142e
      Michael Paquier authored 
      This fixes multiple areas of the documentation:
- COPY for its past compatibility section.
- SET ROLE mentioning INHERITS instead of INHERIT
- PREPARE referring to stmt_name, that is not present.
- Extension documentation about format name with upgrade scripts.

Backpatch down to 9.4 for the relevant parts.

Author: Alexander Lakhin
Discussion: https://postgr.es/m/bf95233a-9943-b341-e2ff-a860c28af481@gmail.com
Backpatch-through: 9.4
      4351142e
  5. 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
  7. 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
  9. 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
  11. 12 Oct, 2019 2 commits
  13. 11 Oct, 2019 1 commit
  15. 10 Oct, 2019 3 commits
  17. 09 Oct, 2019 5 commits
  19. 08 Oct, 2019 4 commits
  21. 07 Oct, 2019 5 commits