1. 24 Aug, 2009 1 commit
    • Tom Lane's avatar
      Fix a violation of WAL coding rules in the recent patch to include an · 7fc7a7c4
      Tom Lane authored
      "all tuples visible" flag in heap page headers.  The flag update *must*
      be applied before calling XLogInsert, but heap_update and the tuple
      moving routines in VACUUM FULL were ignoring this rule.  A crash and
      replay could therefore leave the flag incorrectly set, causing rows
      to appear visible in seqscans when they should not be.  This might explain
      recent reports of data corruption from Jeff Ross and others.
      
      In passing, do a bit of editorialization on comments in visibilitymap.c.
      7fc7a7c4
  2. 23 Aug, 2009 2 commits
    • Tom Lane's avatar
      Make TRUNCATE do truncate-in-place when processing a relation that was created · cab9a065
      Tom Lane authored
      or previously truncated in the current (sub)transaction.  This is safe since
      if the (sub)transaction later rolls back, we'd just discard the rel's current
      physical file anyway.  This avoids unreasonable growth in the number of
      transient files when a relation is repeatedly truncated.  Per a performance
      gripe a couple weeks ago from Todd Cook.
      cab9a065
    • Tom Lane's avatar
      Tweak ExecIndexEvalRuntimeKeys to forcibly detoast any toasted comparison · c38b7594
      Tom Lane authored
      values before they get passed to the index access method.  This avoids
      repeated detoastings that will otherwise ensue as the comparison value
      is examined by various index support functions.  We have seen a couple of
      reports of cases where repeated detoastings result in an order-of-magnitude
      slowdown, so it seems worth adding a bit of extra logic to prevent this.
      
      I had previously proposed trying to avoid duplicate detoastings in general,
      but this fix takes care of what seems the most important case in practice
      with very little effort or risk.
      
      Back-patch to 8.4 so that the PostGIS folk won't have to wait a year to
      have this fix in a production release.  (The issue exists further back,
      of course, but the code's diverged enough to make backpatching further a
      higher-risk action.  Also it appears that the possible gains may be limited
      in prior releases because of different handling of lossy operators.)
      c38b7594
  3. 22 Aug, 2009 1 commit
  4. 20 Aug, 2009 1 commit
  5. 19 Aug, 2009 3 commits
  6. 18 Aug, 2009 10 commits
  7. 17 Aug, 2009 3 commits
  8. 16 Aug, 2009 2 commits
  9. 15 Aug, 2009 3 commits
  10. 14 Aug, 2009 7 commits
  11. 13 Aug, 2009 4 commits
  12. 12 Aug, 2009 3 commits
    • Tom Lane's avatar
      Improve error message for the case where a requested foreign key constraint · b6bde524
      Tom Lane authored
      does match some unique index on the referenced table, but that index is
      only deferrably unique.  We were doing this nicely for the
      default-to-primary-key case, but were being lazy for the other case.
      
      Dean Rasheed
      b6bde524
    • Tom Lane's avatar
    • Tom Lane's avatar
      Allow backends to start up without use of the flat-file copy of pg_database. · 04011cc9
      Tom Lane authored
      To make this work in the base case, pg_database now has a nailed-in-cache
      relation descriptor that is initialized using hardwired knowledge in
      relcache.c.  This means pg_database is added to the set of relations that
      need to have a Schema_pg_xxx macro maintained in pg_attribute.h.  When this
      path is taken, we'll have to do a seqscan of pg_database to find the row
      we need.
      
      In the normal case, we are able to do an indexscan to find the database's row
      by name.  This is made possible by storing a global relcache init file that
      describes only the shared catalogs and their indexes (and therefore is usable
      by all backends in any database).  A new backend loads this cache file,
      finds its database OID after an indexscan on pg_database, and then loads
      the local relcache init file for that database.
      
      This change should effectively eliminate number of databases as a factor
      in backend startup time, even with large numbers of databases.  However,
      the real reason for doing it is as a first step towards getting rid of
      the flat files altogether.  There are still several other sub-projects
      to be tackled before that can happen.
      04011cc9