Re: Having trouble with backups (was: Re: Crash Recovery)
От | Tom Lane |
---|---|
Тема | Re: Having trouble with backups (was: Re: Crash Recovery) |
Дата | |
Msg-id | 28260.1043458181@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Having trouble with backups (was: Re: Crash Recovery) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Having trouble with backups (was: Re: Crash Recovery)
|
Список | pgsql-performance |
I said: > Carlos Moreno <moreno@mochima.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
В списке pgsql-performance по дате отправления: