Re: pg_class and relfilenode
От | muteki muteki |
---|---|
Тема | Re: pg_class and relfilenode |
Дата | |
Msg-id | Law10-F82eWEhrkMNYw0000c598@hotmail.com обсуждение исходный текст |
Ответ на | pg_class and relfilenode ("muteki muteki" <muteki_f@hotmail.com>) |
Ответы |
Re: pg_class and relfilenode
Re: pg_class and relfilenode Re: pg_class and relfilenode |
Список | pgsql-general |
>You don't need to do any data migration to get off 7.2.3 -- 7.2.4 is >a drop-in replacement, so you should at least do that upgrade first. Thanks for the information. If I can simply do a drop-in replacement, that may be something I can try. But I am still thinking there could be other cases database will get corrupted due to power failure and will not be able to startup correctly again. (missing some pg_files) >But I don't think that power failures would be enough to cause the >kind of problem you're describing, unless you're running without >fsync or something. Care to give more details? >In any case, I think that your script is mighty dangerous. It sounds >like a recipe for data loss to me. Postgres is considerably more >robust than this, and I think you're trying to cover up some serious >problems that you may have, likely with your hardware. And you have pointed out my concern. Even though we have WAL enable, we have intentionally disabled both fsync and fdatasync inside the kernel because of other reasons. As long as there are ways I can eliminate database being corrupted (or correctly and automatically detected the corruption and drop the tables if necessary), that should satisfy my need. The persistence of the data is important for me, but disk performance and availability of a funcational database has a higher priority for my need. Thanks, --muteki _________________________________________________________________ Let the advanced features & services of MSN Internet Software maximize your online time. http://click.atdmt.com/AVE/go/onm00200363ave/direct/01/
В списке pgsql-general по дате отправления: