From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Carlos Moreno <moreno(at)mochima(dot)com>, PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Having trouble with backups (was: Re: Crash Recovery) |
Date: | 2003-01-25 01:29:41 |
Message-ID: | 28260.1043458181@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
I said:
> Carlos Moreno <moreno(at)mochima(dot)com> writes:
>> One quick question, Tom, before some general comments and
>> reply to the other messages... Where would I specify any
>> locks the software wants to do?
> If you are not issuing any explicit "LOCK" SQL commands, then you can
> disregard my theory.
Actually, that's too simple. Are you creating and dropping tables,
or issuing schema-change commands (such as ADD COLUMN or RENAME)?
All of those things take exclusive locks on the tables they modify.
Ordinary SELECT/INSERT/UPDATE/DELETE operations can run in parallel with
pg_dump, but messing with the database structure is another story.
I guess the real question here is whether your app is actually stopped
dead (as it would be if waiting for a lock), or just slowed to a crawl
(as a performance problem could do). I cannot tell if your "frozen"
description is hyperbole or literal truth.
One thing that might help diagnose it is to look at the output of ps
auxww (or ps -ef on SysV-ish platforms) to see what all the backends are
currently doing while the problem exists.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-01-25 01:38:44 | Re: WEIRD CRASH?!?! |
Previous Message | Rod Taylor | 2003-01-25 01:20:11 | Re: WEIRD CRASH?!?! |