I have changed "reindex table my_table" to:
psql ...
  -c "drop index my_index; create index my_index;"

We still experience the same "hang" problem.

I was told that this time, the process is
"create index my_index;" before the PG server is

When I login the database, I found the 
my_index is still there.

I do not know what caused this happen, and I 
am also confused. If create index my_index is killed
by "-9", then my_index should not present in the
database because it has been dropped before creating.

On the other hand, if "drop index my_index;" is
killed, then how drop index (which is DDL, right?)
can be blocked? There must be other process(es)
has/have execlusive lock on my_index, which
is not our case from pg_locks.

Tom, we are in the process of installing 
the backend with --enable-debug.


--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Litao Wu <[EMAIL PROTECTED]> writes:
> > One difference between these two databases
> > is the one having REINDEX problem is using
> > NTFS file system. 
> Oh?  That's interesting.
> > Is it possible the root of problem?
> I would not expect it to show this particular
> symptom --- if the
> backtrace is accurate.  But there are nearby places
> that might have
> FS-dependent behavior.  Can you do anything about my
> request for
> a stack trace from a debug-enabled build?
>                       regards, tom lane

Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to