| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
| Cc: | "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, Alfred Perlstein <bright(at)wintelcom(dot)net>, 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-12 00:10:01 |
| Message-ID: | 13250.979258201@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> writes:
> 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?
This is OK for table files, unless someone's broken the code that will
auto-initialize a zero page when it comes across one.
I had a note to myself saying that zeroed pages in indexes may not be
OK, but I'm not sure if that's really a risk or not. btree, at least,
never does any linear scans of an index file; it can only visit pages
that are linked to by parent or sibling links. If we are careful that
we init a btree page before we modify its sibling(s) and parent, we
should be OK.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-01-12 00:13:45 | Re: initdb on build machine and moving to production machine |
| Previous Message | Tom Lane | 2001-01-12 00:03:15 | Re: How to tell if that UPDATE worked? |