Re: unbalanced indexes -> fixed via dump/restore?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alfred Perlstein <bright(at)wintelcom(dot)net>
Cc: will trillich <will(at)serensoft(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: unbalanced indexes -> fixed via dump/restore?
Date: 2001-03-08 14:45:54
Message-ID: 25484.984062754@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alfred Perlstein <bright(at)wintelcom(dot)net> writes:
> * Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [010307 14:30] wrote:
>> Plain old DROP INDEX / CREATE INDEX is probably the best-trodden path.
>> Your (A) seems like vastly more work than is needed. (B) might be
>> marginally easier than DROP/CREATE, but I'm not sure how much I trust
>> REINDEX; it's not been around all that long.

> Is there a way to do this atomically, meaning so that no one can
> get at the table after dropping, but before recreating the index?

In 7.1 it should work to do

begin;
drop index fooi;
create index fooi on foo (...);
end;

The DROP acquires an exclusive lock on foo, so there's no need for
an explicit "lock table foo", though you can add one if it seems
clearer that way.

Before 7.1 this is too risky, because if the create index fails for
some reason, you're hosed (the attempted rollback of DROP will screw up).

btw, REINDEX essentially does the same thing as the above, but there's
a lot of strange additional locking code in it, which I don't trust
much... call it a design disagreement with Hiroshi ;-)

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Daniel A. Melo 2001-03-08 14:59:28 compilation error
Previous Message ryan 2001-03-08 13:41:59 Postrges automatic restart