Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 25 Oct, 2019 3 commits
  3. 24 Oct, 2019 3 commits
  5. 23 Oct, 2019 6 commits
  7. 22 Oct, 2019 2 commits
  9. 21 Oct, 2019 9 commits
  11. 20 Oct, 2019 1 commit
  13. 19 Oct, 2019 5 commits
  15. 18 Oct, 2019 5 commits
  17. 17 Oct, 2019 3 commits
  19. 16 Oct, 2019 3 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