From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Vadim Mikheev <vmikheev(at)sectorbase(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Theory about XLogFlush startup failures |
Date: | 2002-01-15 04:52:01 |
Message-ID: | 3C43B571.1FFA98C6@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > One thing I can think of is to prevent a corrupted page
> > from spoiling other pages by jumping the page boundary
> > in the buffer pool.
> >>
> >> We do that already, no?
>
> > Oh I may be missing something.
> > Where is it checked ?
>
> I know PageRepairFragmentation is real paranoid about this, because I
> made it so recently. I suppose it might be worth adding some more
> sanity checks to PageAddItem, maybe PageZero (is that ever called on a
> pre-existing page?), and PageIndexTupleDelete. Seems like that should
> about cover it --- noplace else inserts items on disk pages or
> reshuffles disk page contents, AFAIK.
What about PageGetItem ? It seems to be able to touch the item
via HeapTupleSatisfies etc.
regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-01-15 04:58:16 | Re: Theory about XLogFlush startup failures |
Previous Message | Bruce Momjian | 2002-01-15 04:45:30 | Re: About pg_upgrade |