RE: Re: Loading optimization - Mailing list pgsql-general

From Mikheev, Vadim
Subject RE: Re: Loading optimization
Date
Msg-id 8F4C99C66D04D4118F580090272A7A234D3263@sectorbase1.sectorbase.com
Whole thread Raw
In response to Loading optimization  (Gary Wesley <gary@db.stanford.edu>)
Responses Re: Re: Loading optimization  (Alfred Perlstein <bright@wintelcom.net>)
Re: Re: Loading optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: "Gregory Wood"
Date:
Subject: Re: How to set "auto commit" off in postgresql db?
Next
From: oberpwd@anubis.network.com (Wade D. Oberpriller)
Date:
Subject: initdb on build machine and moving to production machine