RE: Re: Loading optimization

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема RE: Re: Loading optimization
Дата
Msg-id 8F4C99C66D04D4118F580090272A7A234D3263@sectorbase1.sectorbase.com
обсуждение исходный текст
Ответ на Loading optimization  (Gary Wesley <gary@db.stanford.edu>)
Ответы Re: Re: Loading optimization
Re: Re: Loading optimization
Список pgsql-general
> We have talked about this, but we have not seen enought
> corruption cases to warrant it.

Huh?! Just pg_ctl -m immediate stop in <= 7.0.X with high
insert activity and ... pray.

It's changed in 7.1 by WAL - btree doesn't lose tuples in split
ops anymore and in after crash restart you'll never see btree
tuples pointing to unexisted heap tuples (because of index tuples
inserted/logged after heap ones).

Nevertheless, WAL doesn't guarantee logical consistency of index
in the case of aborted split ops (there may be pages unreferenced
from parent level) - selects will work but inserts may result in
"my bits moved off..." error. I'll try to fix this in 7.1 if I'll
get some time (it doesn't look too hard to do).

Also, WAL doesn't prevent zero blocks in files after crash - I didn't
want to fsync log on each new block allocation, - but this shouldn't
be a problem (except of lost disk space), afair scans are smart to
handle it, Tom? I'm going to fix this with new smgr.

Vadim

В списке pgsql-general по дате отправления:

Предыдущее
От: "Gregory Wood"
Дата:
Сообщение: Re: How to set "auto commit" off in postgresql db?
Следующее
От: oberpwd@anubis.network.com (Wade D. Oberpriller)
Дата:
Сообщение: initdb on build machine and moving to production machine