1. 18 Jun, 2018 1 commit
    • Michael Paquier's avatar
      Prevent hard failures of standbys caused by recycled WAL segments · 70b4f82a
      Michael Paquier authored
      When a standby's WAL receiver stops reading WAL from a WAL stream, it
      writes data to the current WAL segment without having priorily zero'ed
      the page currently written to, which can cause the WAL reader to read
      junk data from a past recycled segment and then it would try to get a
      record from it.  While sanity checks in place provide most of the
      protection needed, in some rare circumstances, with chances increasing
      when a record header crosses a page boundary, then the startup process
      could fail violently on an allocation failure, as follows:
      FATAL:  invalid memory alloc request size XXX
      
      This is confusing for the user and also unhelpful as this requires in
      the worst case a manual restart of the instance, impacting potentially
      the availability of the cluster, and this also makes WAL data look like
      it is in a corrupted state.
      
      The chances of seeing failures are higher if the connection between the
      standby and its root node is unstable, causing WAL pages to be written
      in the middle.  A couple of approaches have been discussed, like
      zero-ing  new WAL pages within the WAL receiver itself but this has the
      disadvantage of impacting performance of any existing instances as this
      breaks the sequential writes done by the WAL receiver.  This commit
      deals with the problem with a more simple approach, which has no
      performance impact without reducing the detection of the problem: if a
      record is found with a length higher than 1GB for backends, then do not
      try any allocation and report a soft failure which will force the
      standby to retry reading WAL.  It could be possible that the allocation
      call passes and that an unnecessary amount of memory is allocated,
      however follow-up checks on records would just fail, making this
      allocation short-lived anyway.
      
      This patch owes a great deal to Tsunakawa Takayuki for reporting the
      failure first, and then discussing a couple of potential approaches to
      the problem.
      
      Backpatch down to 9.5, which is where palloc_extended has been
      introduced.
      
      Reported-by: Tsunakawa Takayuki
      Reviewed-by: Tsunakawa Takayuki
      Author: Michael Paquier
      Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8B57AD@G01JPEXMBYT05
      70b4f82a
  2. 17 Jun, 2018 1 commit
    • Tom Lane's avatar
      Suppress -Wshift-negative-value warnings. · 9b53d966
      Tom Lane authored
      Clean up four places that result in compiler warnings when using recent
      gcc with this warning class enabled (as seen on buildfarm members
      calliphoridae, skink, and others).  In all these places, this is purely
      cosmetic, because the shift distance could not be large enough to risk
      a change of sign, so there's no chance of implementation-dependent
      behavior.  Still, it's easy enough to avoid the warning by casting the
      shifted value to unsigned, so let's do that.
      
      Patch HEAD only, this isn't worth a back-patch.
      9b53d966
  3. 16 Jun, 2018 7 commits
  4. 15 Jun, 2018 3 commits
  5. 14 Jun, 2018 3 commits
  6. 13 Jun, 2018 4 commits
    • Tom Lane's avatar
      Code review for match_clause_to_partition_key(). · 91781335
      Tom Lane authored
      Fix inconsistent decisions about NOMATCH vs UNSUPPORTED result codes.
      If we're going to cater for partkeys that have the same expression and
      different collations, surely we should also support partkeys with the
      same expression and different opclasses.
      
      Clean up shaky handling of commuted opclauses, eg checking the wrong
      operator to see what its negator is.  This wouldn't cause any actual
      bugs given a sane opclass definition, but it doesn't seem helpful to
      expend more code to be less correct.
      
      Improve handling of null elements in ScalarArrayOp arrays: in the
      "op ALL" case, we can conclude they result in an unsatisfiable clause.
      
      Minor cosmetic changes and comment improvements.
      91781335
    • Tom Lane's avatar
      Fix some ill-chosen names for globally-visible partition support functions. · 19832753
      Tom Lane authored
      "compute_hash_value" is particularly gratuitously generic, but IMO
      all of these ought to have names clearly related to partitioning.
      19832753
    • Tom Lane's avatar
      Fix up run-time partition pruning's use of relcache's partition data. · e23bae82
      Tom Lane authored
      The previous coding saved pointers into the partitioned table's relcache
      entry, but then closed the relcache entry, causing those pointers to
      nominally become dangling.  Actual trouble would be seen in the field
      only if a relcache flush occurred mid-query, but that's hardly out of
      the question.
      
      While we could fix this by copying all the data in question at query
      start, it seems better to just hold the relcache entry open for the
      whole query.
      
      While at it, improve the handling of support-function lookups: do that
      once per query not once per pruning test.  There's still something to be
      desired here, in that we fail to exploit the possibility of caching data
      across queries in the fn_extra fields of the relcache's FmgrInfo structs,
      which could happen if we just used those structs in-place rather than
      copying them.  However, combining that with the possibility of per-query
      lookups of cross-type comparison functions seems to require changes in the
      APIs of a lot of the pruning support functions, so it's too invasive to
      consider as part of this patch.  A win would ensue only for complex
      partition key data types (e.g. arrays), so it may not be worth the
      trouble.
      
      David Rowley and Tom Lane
      
      Discussion: https://postgr.es/m/17850.1528755844@sss.pgh.pa.us
      e23bae82
    • Alexander Korotkov's avatar
      Documentation improvement for pg_trgm · e146e4d0
      Alexander Korotkov authored
      Documentation of word_similarity() and strict_word_similarity() functions
      contains some vague wordings which could confuse users.  This patch makes
      those wordings more clear.  word_similarity() was introduced in PostgreSQL 9.6,
      and corresponding part of documentation needs to be backpatched.
      
      Author: Bruce Momjian, Alexander Korotkov
      Discussion: https://postgr.es/m/20180526165648.GB12510%40momjian.us
      Backpatch: 9.6, where word_similarity() was introduced
      e146e4d0
  7. 12 Jun, 2018 5 commits
  8. 11 Jun, 2018 13 commits
  9. 10 Jun, 2018 3 commits