Обсуждение: Re: [HACKERS] 7.0 status request

--- Jan Wieck <wieck@debis.com> wrote:
> Bruce Momjian wrote:
> 
> > > > Here are the major open issues for 7.0 that I remember:
> > > >         Foreign Keys   - Jan
> > > >         WAL            - Vadim
> > > >         Function args  - Tom
> > > >         System indcxes - Bruce
> > > > Outer joins and new multi-query parse tree are questionable items
> for
> > > > 7.0.
> > >
> > > You might include "join syntax", which will be ready even if outer
> > > joins are not.
> > >
> > > Also, didn't some folks express concern that indices on system
> tables
> > > would make the backend more fragile? Did we resolve that issue?
> >
> > We have indexes on most system tables and it isn't a problem
> currently.
> 
>     It  is, because a corrupted index on a system table cannot be
>     corrected by drop/create, as a user defined index could be.
> 
>     I don't know why and when  reindexdb  disappeared,  but  that
>     script  was  a  last  resort  for  exactly the situation of a
>     corrupted  system  index.   Let  me  take  a  look  if   this
>     functionality could easily be recreated.
> 
> 
> Jan
> 
> --
> 
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.                                  #
> #========================================= wieck@debis.com (Jan Wieck) #

For what its worth, TRUNCATE TABLE already rebuilds indexes on TRUNCATE'd
tables, so it shouldn't be that much of a leap, one would think.

Mike Mascari
(mascarim@yahoo.com)



__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

Mike Mascari wrote:

> >     It  is, because a corrupted index on a system table cannot be
> >     corrected by drop/create, as a user defined index could be.
> >
> >     I don't know why and when  reindexdb  disappeared,  but  that
> >     script  was  a  last  resort  for  exactly the situation of a
> >     corrupted  system  index.   Let  me  take  a  look  if   this
> >     functionality could easily be recreated.
>
> For what its worth, TRUNCATE TABLE already rebuilds indexes on TRUNCATE'd
> tables, so it shouldn't be that much of a leap, one would think.

    Imagine  a  corrupted pg_attribute_attrelid_index. What would
    it be good for to do a TRUNCATE TABLE pg_attribute? For god's
    sake, it's not permitted.

    I'm talking about corrupted system catalog indices! There's a
    substantial difference for them. If only one is missing,  you
    might  not  be  able to even connect to that database because
    the backend wouldn't start up.  The problem here is, that the
    system  catalog's  partially  reside in a shared memory cache
    during the lifetime  of  a  postmaster!   And  remember,  one
    postmaster  can  server  many  databases.   There  are REALLY
    different semantics!

    Please folks, it's nice if you succeded in recovering from  a
    corrupted  index.  But as long as it's name didn't start with
    pg_, it's not what I'm talking about.

    Maybe a directly  issued  index_build()  from  the  bootstrap
    interface  might help. Will create another bootparser command
    and give it a try.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #