Re: Corrupted DB? could not open file pg_clog/####
От | Francisco Reyes |
---|---|
Тема | Re: Corrupted DB? could not open file pg_clog/#### |
Дата | |
Msg-id | cone.1154293114.148408.42196.1000@zoraida.natserv.net обсуждение исходный текст |
Ответ на | Corrupted DB? could not open file pg_clog/#### (Francisco Reyes <lists@stringsutils.com>) |
Ответы |
Re: Corrupted DB? could not open file pg_clog/####
|
Список | pgsql-general |
Martijn van Oosterhout writes: > It's still a reasonable suggestion. The maximum offset is the number of > rows in the table. You'll notice when the output is empty. Once I find the point where the output is empty then what? > Do you have > an idea how much data it contains? Yes. Around 87 million rows. > If you connect via psql, you can set the client_min_message to DEBUG to > get some more stuff. How? Tried set client_min_message='DEBUG'; > Well, it will stop complaining. What will happen is that any > transactions involving those transaction IDs will be assumed to have > been committed. If the pg_clog files are to keep track of transactions, shouldn't a "pg_ctl restart" rollback all pending transactions.. so there are no pending transactions upon the restart and this error should not appear again? Using 8.1.4 > This may be ok, but in extreme cases it could lead to > broken constraints. That exteme case sounds pretty bad. :-( Will it be safe to do after a restart? After all there should not be any transactions.. > However, pg_clog/0000 is the very first transaction file created. Is it > in the range of the files that do do exist? There are 228 files in the directory and the oldest one is "016E" from about a month ago. > Are you sure some other > process didn't remove it accedently? Not that I can think off. I didn't even know what this diretory was until this problem showed up.. much less delete anything from it.
В списке pgsql-general по дате отправления: