1. 23 Feb, 1998 1 commit
    • Marc G. Fournier's avatar
      From: Jan Wieck <jwieck@debis.com> · 6c7c6d0c
      Marc G. Fournier authored
          The diff looks so simple and easy. But to find it wasn't fun.
      
          It must have been there for a long time. What happened:
      
          When a tuple in one of some central catalogs was updated, the
          referenced  relation  got flushed, so it would be reopened on
          the next access (to reflect new  triggers,  rules  and  table
          structure changes into the relation cache).
      
          Some  data  (the  tupleDescriptor e.g.) is used in the system
          cache too. So when a relation is subject to the system cache,
          this  must know too that a cached system relation got flushed
          because the tupleDesc data gets freed during the flush!
      
          For the GRANT/REVOKE on pg_class it was  slightly  different.
          There  is some local data in inval.c that gets initialized on
          the first invalidation of a tuple in some  central  catalogs.
          This  needs a SysCache lookup in pg_class. But when the first
          of all commands is a GRANT on pg_class,  exactly  the  needed
          tuple is the one actually invalidated. So I added little code
          snippets that the initialization of the  local  variables  in
          inval.c will already happen during InitPostgres().
      6c7c6d0c
  2. 29 Jan, 1998 1 commit
    • Marc G. Fournier's avatar
      From: Phil Thompson <phil@river-bank.demon.co.uk> · 8e789e8e
      Marc G. Fournier authored
      Attached is the patch to fix the warning messages from my code.  I also
      fixed one which wasn't my code.  Apart from the usual warnings about the
      bison/yacc generated code I only have one other warning message.  This
      is in gramm.y around line 2234.  I wasn't sure of the fix.
      
      I've also replaced all the calls to free() in gramm.y to calls to
      pfree().  Without these I was getting backend crashes with GRANT.  This
      might already have been fixed.
      8e789e8e
  3. 20 Dec, 1997 1 commit
  4. 24 Nov, 1997 1 commit
  5. 18 Nov, 1997 1 commit
  6. 17 Nov, 1997 1 commit
  7. 10 Nov, 1997 1 commit
  8. 07 Nov, 1997 2 commits
  9. 08 Sep, 1997 1 commit
  10. 07 Sep, 1997 1 commit
  11. 27 Aug, 1997 1 commit
  12. 19 Aug, 1997 1 commit
  13. 12 Aug, 1997 1 commit
  14. 24 Jul, 1997 1 commit
  15. 14 Feb, 1997 1 commit
  16. 08 Jan, 1997 1 commit
  17. 12 Nov, 1996 1 commit
  18. 08 Nov, 1996 1 commit
  19. 06 Nov, 1996 1 commit
  20. 31 Oct, 1996 1 commit
  21. 27 Aug, 1996 1 commit
  22. 09 Jul, 1996 1 commit