Re: Re: Loading optimization

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

In response to

Browse pgsql-general by date

  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?