| From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
|---|---|
| To: | "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, Alfred Perlstein <bright(at)wintelcom(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ian Harding <iharding(at)pakrat(dot)com>, Martijn van Oosterhout <kleptog(at)cupid(dot)suninternet(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | RE: Re: Loading optimization |
| Date: | 2001-01-11 22:10:24 |
| Message-ID: | 8F4C99C66D04D4118F580090272A7A234D3263@sectorbase1.sectorbase.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Wade D. Oberpriller | 2001-01-11 22:28:40 | initdb on build machine and moving to production machine |
| Previous Message | Gregory Wood | 2001-01-11 21:28:58 | Re: How to set "auto commit" off in postgresql db? |