Re: Superuser lost access to particular database
От | Francisco Reyes |
---|---|
Тема | Re: Superuser lost access to particular database |
Дата | |
Msg-id | cone.1158077087.800256.60510.1000@zoraida.natserv.net обсуждение исходный текст |
Ответ на | Superuser lost access to particular database (Francisco Reyes <lists@stringsutils.com>) |
Ответы |
Re: Superuser lost access to particular database
|
Список | pgsql-general |
Tom Lane writes: > Define "freezes". What happens exactly doing pg_dump <db> |tee <outfile> Shows nothing. This database is not very big so I would expect it to be done quickly. I tried a couple of other databases and they did the pg_dump without problems. >is the pg_dump or its backend consuming CPU, or just sitting? At 90% of my CPU. > What do ps and pg_stat_activity > and pg_locks show that it's doing? To make sure it was not a locking issue I did pg_ctl restart.. checked that there were no locks or pretty much anything going on.. and then tried again. > (I'm speculating in particular that someone is holding an exclusive lock > on one of the tables to be dumped --- if so pg_locks would tell the tale.) Doing it with a freshly restarted postgresql. I have loggin set log_min_messages = info and log_statement = 'all'. Right after I start the pg_dump there is a flury of activity, which I am putting at http://public.natserv.net/pg_dump_log.txt, but very quickly it stops producing any output to the log. I left it for about 10 minutes and nothing was showing to the log.
В списке pgsql-general по дате отправления: