Litao Wu <[EMAIL PROTECTED]> writes:
> Since there are multiple databases and
> there are 170 postgres processes this morning,
> 60 of them are access the problem database,
> and 57 of 60 are non-idle.
> We only need to gdb those 57 processes, or
> we need gdb 60 or 170?
Potentially the deadlock
Thanks!
OK, we will do this exceise next time.
TSince there are multiple databases and
there are 170 postgres processes this morning,
60 of them are access the problem database,
and 57 of 60 are non-idle.
We only need to gdb those 57 processes, or
we need gdb 60 or 170?
Thanks again!
--- Tom
Litao Wu <[EMAIL PROTECTED]> writes:
> Our PG version is 7.3.2.
Hmm. On general principles you should be using 7.3.6, but I do not see
anything in the 7.3.* change logs that looks very likely to cure this.
> The copy process is always there. Besides copy
> process, there are many select processe
Hi Tom,
Our PG version is 7.3.2.
The copy process is always there. Besides copy
process, there are many select processes wait also
(it is understandable only when reindex,
but how come selects wait when drop/create index?
>From Postgres doc:
Note: Another approach to dealing with a corrupted
user
Litao Wu <[EMAIL PROTECTED]> writes:
> It happened again.
> This time it hangs when we drop/create index.
> Here is gdb info with --enable-debug postgres.
Well, that pretty much removes all doubt: something has left the buffer
context lock (cntx_lock) set on a buffer that certainly ought to be fr
Hi All,
It happened again.
This time it hangs when we drop/create index.
Here is gdb info with --enable-debug postgres.
Thank you for your help!
postgres 24533 24327 2 Jun28 ?00:39:11
postgres: postgres
xxx xxx.xxx.x.xxx COPY waiting
postgres 23508 24327 0 03:23 ?00:00:00
po
Litao Wu <[EMAIL PROTECTED]> writes:
> I have changed "reindex table my_table" to:
> psql ...
> -c "drop index my_index; create index my_index;"
> 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 t
Hi,
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
bounced.
When I login the database, I found the
my
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 accurat
We have another production database,
which is similar with this one.
It has never had REINDEX block problem yet.
One difference between these two databases
is the one having REINDEX problem is using
NTFS file system.
Is it possible the root of problem?
Thanks,
--- Tom Lane <[EMAIL PROTECTED]>
Litao Wu <[EMAIL PROTECTED]> writes:
> (gdb) bt
> #0 0x420e8bb2 in semop () from /lib/i686/libc.so.6
> #1 0x080ffa28 in PGSemaphoreLock ()
> #2 0x08116432 in LWLockAcquire ()
> #3 0x0810f572 in LockBuffer ()
> #4 0x0807dea3 in _bt_getbuf ()
> #5 0x080813ec in _bt_leafbuild ()
> #6 0x080816a6
Hi Tom,
Here is gdb info.
This happens in our production database
3 times this week. It's totally unacceptable.
I have written a drop/create script to
avoid reindex. However, drop/create
seems to me take more time than reindex
for the whole database.
Your help is greatly appreciated!
Version:
Litao Wu <[EMAIL PROTECTED]> writes:
> I will use gdb next time. What's this right way to
> get info as postgres owner?
$ gdb /path/to/postgres
gdb> attach PID-of-backend-process
gdb> bt
gdb> quit
You might try this for practice on any idle backend; it shouldn't af
Thank you, Tom!
We vacuum and reindex every night and
reindex typically took 30 minutes. Today,
it ran since 3AM, and has not finished till 8:30AM.
The email and its indexe sizes are:
tablename indexname size_kb reltuples
email 1292696 8.07905e+06
email e
Litao Wu <[EMAIL PROTECTED]> writes:
> We often experience with the problem that reindex
> cannot be finished in our production database.
> It's typically done with 30 minutes. However,
> sometimes, when there is another "COPY" process,
> reindex will not finish. By monitoring the CPU
> time rei
Hi,
We often experience with the problem that reindex
cannot be finished in our production database.
It's typically done with 30 minutes. However,
sometimes, when there is another "COPY" process,
reindex will not finish. By monitoring the CPU
time reindex takes, it does not increase at all.
Tha
16 matches
Mail list logo
