On 11/16/2010 07:25 PM, Tom Lane wrote:
2. What's proposed as the new feature is that specific non-system tables can be marked as unlogged, meaning that WAL entries won't be made for changes in those tables' contents (nor their indexes' contents). So we can't guarantee that the contents of such tables will be correct or consistent after a crash. The proposed feature deals with this by forcibly truncating all such tables after a crash, thus ensuring that they're consistent though not populated. So the possible use-cases for such tables are limited to where (a) you can repopulate the tables on demand, or (b) you don't really care about losing data on a crash.
Well if you guys would just hurry up and implement a way to mark indexes as inconsistent and continue to run without using them, you'd at least have the index problem solved :D
I was one of the guys drooling over WAL way back when it was a new feature. I understand the risks in not logging updates, and most of the time won't accept the risk if I don't absolutely have to. But, OTOH, before WAL, ALL tables were unlogged, and we still never lost any data that I'm aware of. I don't remember ever having anything worse than errors from corrupt indexes.
Maybe there's some old code somewhere to repair PG tables that could be dusted off and updated...?
Heck, even if the postmaster refused to do anything with tables it thought might be FUBAR, and we had to repair them to even issue selects against them, in some cases that would still be better than having all the data go *poof*.
-Glen -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
