1. 21 Nov, 2006 4 commits
    • Bruce Momjian's avatar
      Add capitalization mention. · cc6c10a7
      Bruce Momjian authored
      cc6c10a7
    • Bruce Momjian's avatar
      I noticed that the Partitioning section of the docs has *two* sections · 150328cd
      Bruce Momjian authored
      of caveats in different places, but close together. One called caveats,
      one not. That looks like it just led to somebody not reading some
      appropriate caveats in the second group of caveats (on -admin).
      
      Simon Riggs
      150328cd
    • Tom Lane's avatar
      Change the default setting for log_min_error_statement to ERROR. Per · 414c7a53
      Tom Lane authored
      recent discussion in which majority opinion was that this is a more
      widely useful setting than the previous default of PANIC.
      414c7a53
    • Tom Lane's avatar
      Adjust elog.c so that elog(FATAL) exits (including cases where ERROR is · e82d9e62
      Tom Lane authored
      promoted to FATAL) end in exit(1) not exit(0).  Then change the postmaster to
      allow exit(1) without a system-wide panic, but not for the startup subprocess
      or the bgwriter.  There were a couple of places that were using exit(1) to
      deliberately force a system-wide panic; adjust these to be exit(2) instead.
      This fixes the problem noted back in July that if the startup process exits
      with elog(ERROR), the postmaster would think everything is hunky-dory and
      proceed to start up.  Alternative solutions such as trying to run the entire
      startup process as a critical section seem less clean, primarily because of
      the fact that a fair amount of startup code is shared by all postmaster
      children in the EXEC_BACKEND case.  We'd need an ugly special case somewhere
      near the head of main.c to make it work if it's the child process's
      responsibility to determine what happens; and what's the point when the
      postmaster already treats different children differently?
      e82d9e62
  2. 20 Nov, 2006 10 commits
  3. 19 Nov, 2006 1 commit
    • Tom Lane's avatar
      Repair problems with hash indexes that span multiple segments: the hash code's · d68efb3f
      Tom Lane authored
      preference for filling pages out-of-order tends to confuse the sanity checks
      in md.c, as per report from Balazs Nagy in bug #2737.  The fix is to ensure
      that the smgr-level code always has the same idea of the logical EOF as the
      hash index code does, by using ReadBuffer(P_NEW) where we are adding a single
      page to the end of the index, and using smgrextend() to reserve a large batch
      of pages when creating a new splitpoint.  The patch is a bit ugly because it
      avoids making any changes in md.c, which seems the most prudent approach for a
      backpatchable beta-period fix.  After 8.3 development opens, I'll take a look
      at a cleaner but more invasive patch, in particular getting rid of the now
      unnecessary hack to allow reading beyond EOF in mdread().
      
      Backpatch as far as 7.4.  The bug likely exists in 7.3 as well, but because
      of the magnitude of the 7.3-to-7.4 changes in hash, the later-version patch
      doesn't even begin to apply.  Given the other known bugs in the 7.3-era hash
      code, it does not seem worth trying to develop a separate patch for 7.3.
      d68efb3f
  4. 17 Nov, 2006 9 commits
  5. 16 Nov, 2006 5 commits
  6. 15 Nov, 2006 1 commit
  7. 14 Nov, 2006 4 commits
  8. 13 Nov, 2006 1 commit
  9. 12 Nov, 2006 3 commits
  10. 11 Nov, 2006 1 commit
  11. 10 Nov, 2006 1 commit