1. 08 Nov, 2018 4 commits
    • Tom Lane's avatar
      Disallow setting client_min_messages higher than ERROR. · 3d360e20
      Tom Lane authored
      Previously it was possible to set client_min_messages to FATAL or PANIC,
      which had the effect of suppressing transmission of regular ERROR messages
      to the client.  Perhaps that seemed like a useful option in the past, but
      the trouble with it is that it breaks guarantees that are explicitly made
      in our FE/BE protocol spec about how a query cycle can end.  While libpq
      and psql manage to cope with the omission, that's mostly because they
      are not very bright; client libraries that have more semantic knowledge
      are likely to get confused.  Notably, pgODBC doesn't behave very sanely.
      Let's fix this by getting rid of the ability to set client_min_messages
      above ERROR.
      
      In HEAD, just remove the FATAL and PANIC options from the set of allowed
      enum values for client_min_messages.  (This change also affects
      trace_recovery_messages, but that's OK since these aren't useful values
      for that variable either.)
      
      In the back branches, there was concern that rejecting these values might
      break applications that are explicitly setting things that way.  I'm
      pretty skeptical of that argument, but accommodate it by accepting these
      values and then internally setting the variable to ERROR anyway.
      
      In all branches, this allows a couple of tiny simplifications in the
      logic in elog.c, so do that.
      
      Also respond to the point that was made that client_min_messages has
      exactly nothing to do with the server's logging behavior, and therefore
      does not belong in the "When To Log" subsection of the documentation.
      The "Statement Behavior" subsection is a better match, so move it there.
      
      Jonah Harris and Tom Lane
      
      Discussion: https://postgr.es/m/7809.1541521180@sss.pgh.pa.us
      Discussion: https://postgr.es/m/15479-ef0f4cc2fd995ca2@postgresql.org
      3d360e20
    • Alvaro Herrera's avatar
      Revise attribute handling code on partition creation · 705d433f
      Alvaro Herrera authored
      The original code to propagate NOT NULL and default expressions
      specified when creating a partition was mostly copy-pasted from
      typed-tables creation, but not being a great match it contained some
      duplicity, inefficiency and bugs.
      
      This commit fixes the bug that NOT NULL constraints declared in the
      parent table would not be honored in the partition.  One reported issue
      that is not fixed is that a DEFAULT declared in the child is not used
      when inserting through the parent.  That would amount to a behavioral
      change that's better not back-patched.
      
      This rewrite makes the code simpler:
      
      1. instead of checking for duplicate column names in its own block,
      reuse the original one that already did that;
      
      2. instead of concatenating the list of columns from parent and the one
      declared in the partition and scanning the result to (incorrectly)
      propagate defaults and not-null constraints, just scan the latter
      searching the former for a match, and merging sensibly.  This works
      because we know the list in the parent is already correct and there can
      only be one parent.
      
      This rewrite makes ColumnDef->is_from_parent unused, so it's removed
      on branch master; on released branches, it's kept as an unused field in
      order not to cause ABI incompatibilities.
      
      This commit also adds a test case for creating partitions with
      collations mismatching that on the parent table, something that is
      closely related to the code being patched.  No code change is introduced
      though, since that'd be a behavior change that could break some (broken)
      working applications.
      
      Amit Langote wrote a less invasive fix for the original
      NOT NULL/defaults bug, but while I kept the tests he added, I ended up
      not using his original code.  Ashutosh Bapat reviewed Amit's fix.  Amit
      reviewed mine.
      
      Author: Álvaro Herrera, Amit Langote
      Reviewed-by: Ashutosh Bapat, Amit Langote
      Reported-by: Jürgen Strobel (bug #15212)
      Discussion: https://postgr.es/m/152746742177.1291.9847032632907407358@wrigleys.postgresql.org
      705d433f
    • Andrew Dunstan's avatar
      Adjust valgrind fix in commit 517b0d0b · 12d5f39b
      Andrew Dunstan authored
      lousyjack still wasn't happy. I have tested this modification and it
      worked.
      12d5f39b
    • Michael Paquier's avatar
  2. 07 Nov, 2018 9 commits
  3. 06 Nov, 2018 13 commits
  4. 05 Nov, 2018 6 commits
  5. 04 Nov, 2018 4 commits
  6. 03 Nov, 2018 4 commits