1. 08 Jul, 2018 2 commits
  2. 07 Jul, 2018 1 commit
  3. 06 Jul, 2018 6 commits
  4. 05 Jul, 2018 7 commits
    • Alvaro Herrera's avatar
      logical decoding: beware of an unset specinsert change · 3ca966c0
      Alvaro Herrera authored
      Coverity complains that there is no protection in the code (at least in
      non-assertion-enabled builds) against speculative insertion failing to
      follow the expected protocol.  Add an elog(ERROR) for the case.
      3ca966c0
    • Peter Eisentraut's avatar
      doc: Reword old inheritance partitioning documentation · 0c06534b
      Peter Eisentraut authored
      Prefer to use phrases like "child" instead of "partition" when
      describing the legacy inheritance-based partitioning.  The word
      "partition" now has a fixed meaning for the built-in partitioning, so
      keeping it out of the documentation of the old method makes things
      clearer.
      
      Author: Justin Pryzby <pryzby@telsasoft.com>
      0c06534b
    • Peter Eisentraut's avatar
      doc: Fix typos · 17411e0f
      Peter Eisentraut authored
      Author: Justin Pryzby <pryzby@telsasoft.com>
      17411e0f
    • Alvaro Herrera's avatar
      Reduce cost of test_decoding's new oldest_xmin test · 8d1c1ca7
      Alvaro Herrera authored
      Change a whole-database VACUUM into doing just pg_attribute, which is
      the portion that verifies what we want it to do.  The original
      formulation wastes a lot of CPU time, which leads the test to fail when
      runtime exceeds isolationtester timeout when it's super-slow, such as
      under CLOBBER_CACHE_ALWAYS.  Per buildfarm member friarbird.
      
      It turns out that the previous shape of the test doesn't always detect
      the condition it is supposed to detect (on unpatched reorderbuffer
      code): the reason is that there is a good chance of encountering a
      xl_running_xacts record (logged every 15 seconds) before the checkpoint
      -- and because we advance the xmin when we receive that WAL record, and
      we *don't* advance the xmin twice consecutively without receiving a
      client message in between, that means the xmin is not advanced enough
      for the tuple to be pruned from pg_attribute by VACUUM.  So the test
      would spuriously pass.
      
      The reason this test deficiency wasn't detected earlier is that HOT
      pruning removes the tuple anyway, even if vacuum leaves it in place, so
      the test correctly fails (detecting the coding mistake), but for the
      wrong reason.
      
      To fix this mess, run the s0_get_changes step twice before vacuum
      instead of once: this seems to cause the xmin to be advanced reliably,
      wreaking havoc with more certainty.
      
      Author: Arseny Sher
      Discussion: https://postgr.es/m/87h8lkuxoa.fsf@ars-thinkpad
      8d1c1ca7
    • Peter Eisentraut's avatar
      Fix typo · f61988d1
      Peter Eisentraut authored
      f61988d1
    • Michael Paquier's avatar
      Prevent references to invalid relation pages after fresh promotion · 3c64dcb1
      Michael Paquier authored
      If a standby crashes after promotion before having completed its first
      post-recovery checkpoint, then the minimal recovery point which marks
      the LSN position where the cluster is able to reach consistency may be
      set to a position older than the first end-of-recovery checkpoint while
      all the WAL available should be replayed.  This leads to the instance
      thinking that it contains inconsistent pages, causing a PANIC and a hard
      instance crash even if all the WAL available has not been replayed for
      certain sets of records replayed.  When in crash recovery,
      minRecoveryPoint is expected to always be set to InvalidXLogRecPtr,
      which forces the recovery to replay all the WAL available, so this
      commit makes sure that the local copy of minRecoveryPoint from the
      control file is initialized properly and stays as it is while crash
      recovery is performed.  Once switching to archive recovery or if crash
      recovery finishes, then the local copy minRecoveryPoint can be safely
      updated.
      
      Pavan Deolasee has reported and diagnosed the failure in the first
      place, and the base fix idea to rely on the local copy of
      minRecoveryPoint comes from Kyotaro Horiguchi, which has been expanded
      into a full-fledged patch by me.  The test included in this commit has
      been written by Álvaro Herrera and Pavan Deolasee, which I have modified
      to make it faster and more reliable with sleep phases.
      
      Backpatch down to all supported versions where the bug appears, aka 9.3
      which is where the end-of-recovery checkpoint is not run by the startup
      process anymore.  The test gets easily supported down to 10, still it
      has been tested on all branches.
      
      Reported-by: Pavan Deolasee
      Diagnosed-by: Pavan Deolasee
      Reviewed-by: Pavan Deolasee, Kyotaro Horiguchi
      Author: Michael Paquier, Kyotaro Horiguchi, Pavan Deolasee, Álvaro
      Herrera
      Discussion: https://postgr.es/m/CABOikdPOewjNL=05K5CbNMxnNtXnQjhTx2F--4p4ruorCjukbA@mail.gmail.com
      3c64dcb1
    • Andres Freund's avatar
      Use context with correct lifetime in hypothetical_dense_rank_final. · 249126e7
      Andres Freund authored
      The query lifetime expression context created in
      hypothetical_dense_rank_final() was buggily allocated in the calling
      memory context. I (Andres) broke that in bf6c614a.
      
      Reported-By: Rajkumar Raghuwanshi
      Author: Amit Langote
      Discussion:  https://postgr.es/m/CAKcux6kmzWmur5HhA_aU6gYVFu0RLQdgJJ+aC9SLdcOvBSrpfA@mail.gmail.com
      Backpatch: 11-
      249126e7
  5. 04 Jul, 2018 4 commits
    • Andres Freund's avatar
      Check for interrupts inside the nbtree page deletion code. · 3a01f68e
      Andres Freund authored
      When deleting pages the nbtree code has to walk through siblings of a
      tree node. When those sibling links are corrupted that can lead to
      endless loops - which are currently not interruptible.  This is
      especially problematic if autovacuum is repeatedly blocked on such
      indexes, as it can be hard to get out of that situation without
      resorting to single user mode.
      
      Thus add interrupt checks to appropriate places in such
      loops. Unfortunately in one of the cases it's it's not easy to do so.
      
      Between 9.3 and 9.4 the page deletion (and page split) code changed
      significantly. Before it was significantly less robust against
      interruptions. Therefore don't backpatch to 9.3.
      
      Author: Andres Freund
      Discussion: https://postgr.es/m/20180627191629.wkunw2qbibnvlz53@alap3.anarazel.de
      Backpatch: 9.4-
      3a01f68e
    • Fujii Masao's avatar
      Improve the performance of relation deletes during recovery. · b4166911
      Fujii Masao authored
      When multiple relations are deleted at the same transaction,
      the files of those relations are deleted by one call to smgrdounlinkall(),
      which leads to scan whole shared_buffers only one time. OTOH,
      previously, during recovery, smgrdounlink() (not smgrdounlinkall()) was
      called for each file to delete, which led to scan shared_buffers
      multiple times. Obviously this could cause to increase the WAL replay
      time very much especially when shared_buffers was huge.
      
      To alleviate this situation, this commit changes the recovery so that
      it also calls smgrdounlinkall() only one time to delete multiple
      relation files.
      
      This is just fix for oversight of commit 279628a0, not new feature.
      So, per discussion on pgsql-hackers, we concluded to backpatch this
      to all supported versions.
      
      Author: Fujii Masao
      Reviewed-by: Michael Paquier, Andres Freund, Thomas Munro, Kyotaro Horiguchi, Takayuki Tsunakawa
      Discussion: https://postgr.es/m/CAHGQGwHVQkdfDqtvGVkty+19cQakAydXn1etGND3X0PHbZ3+6w@mail.gmail.com
      b4166911
    • Peter Eisentraut's avatar
      doc: Reorganize CREATE TABLE / LIKE option documentation · b46727e0
      Peter Eisentraut authored
      This section once started out small but has now grown quite a bit and
      needs a bit of structure.
      
      Rewrite as list, add documentation of EXCLUDING, and improve the
      documentation of INCLUDING ALL instead of just listing all the options
      again.
      
      per report from Yugo Nagata that EXCLUDING was not documented, that part
      reviewed by Daniel Gustafsson, most of the rewrite was by me
      b46727e0
    • Michael Paquier's avatar
      Remove dead code for temporary relations in partition planning · fc057b2b
      Michael Paquier authored
      Since recent commit 1c7c317c, temporary relations cannot be mixed with
      permanent relations within the same partition tree, and the same counts
      for temporary relations created by other sessions, which the planner
      simply discarded.  Instead be paranoid and issue an error, as those
      should be blocked at definition time, at least for now.
      
      At the same time, a test case is added to stress what has been moved
      when expand_partitioned_rtentry gets called recursively but bumps on a
      partitioned relation with no partitions which should be handled the same
      way as the non-inheritance case.  This code may be reworked in a close
      future, and covering this code path will limit surprises.
      
      Reported-by: David Rowley
      Author: David Rowley
      Reviewed-by: Amit Langote, Robert Haas, Michael Paquier
      Discussion: https://postgr.es/m/CAKJS1f_HyV1txn_4XSdH5EOhBMYaCwsXyAj6bHXk9gOu4JKsbw@mail.gmail.com
      fc057b2b
  6. 03 Jul, 2018 2 commits
  7. 02 Jul, 2018 2 commits
  8. 01 Jul, 2018 6 commits
  9. 30 Jun, 2018 4 commits
  10. 29 Jun, 2018 6 commits