| 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 01:00:15 |
| Message-ID: | 13550.979261215@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:
>> This is OK for table files, unless someone's broken the code that will
>> auto-initialize a zero page when it comes across one.
> Hmmm, I don't see anything like auto-initialization in code -:(
> Where did you put these changes?
I didn't put 'em in, it looked like your work to me: see vacuum.c,
lines 618-622 in current sources.
Awhile back I did fix PageGetFreeSpace and some related macros to
deliver sane results when looking at an all-zero page header, so that
scans and inserts would ignore the page until vacuum fixes it.
Perhaps WAL redo needs to be prepared to do PageInit as well?
Actually, I'd expect the CRC check to catch an all-zeroes page (if
it fails to complain, then you misimplemented the CRC), so that would
be the place to deal with it now.
>> If we are careful that
>> we init a btree page before we modify its sibling(s) and parent, we
>> should be OK.
> Should be covered by WALoging of newroot & split ops which only add
> new pages.
OK, sounds good.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mikheev, Vadim | 2001-01-12 01:19:29 | RE: Re: Loading optimization |
| Previous Message | Tom Lane | 2001-01-12 00:43:27 | Re: postmaster won't run |