I have changed "reindex table my_table" to:
-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