Re: quick review
От | Joshua D. Drake |
---|---|
Тема | Re: quick review |
Дата | |
Msg-id | 1164145160.24113.150.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: quick review (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
On Tue, 2006-11-21 at 16:18 -0500, Andrew Dunstan wrote: > Joshua D. Drake wrote: > >> Unless you have buggy hardware, there is no need for a repair tool. > >> That is our position. > >> > > > > And when I mentioned that to two of my largest customers, they both > > looked at me like I had lost my mind. > > > > Something to think about. > > > > > > Now ask your clients what errors they see that could be fixed by a > repair tool. I think Bruce's formulation is unfortunate, and would look > better like this: When we find that there is a bug that causes data > corruption we fix the bug rather than supplying a workaround. Our > position is that repair tools are mostly a bandaid, and we would rather > fix the problem. I have a customer right now, that has a corrupted table. The table would be fixed by deleting a couple of rows. Now, I don't know if this is true but I could find it useful to do something like: table_check -U postgres -D foo -t corrupted_table WARNING: 2 rows bad, writing out to disk NOTICE: 100000 million rows cleaned NOTICE: table corrupted_table clean Then I could go to a file and get some semblence of information on what rows were bad so I could find them from an old backup or something. The reason this is important is that a single bad row in a 500Gb database, prevents backups. Sincerely, Joshua D. Drake > cheers > > andrew > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
В списке pgsql-hackers по дате отправления: