From: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Checkpoint cost, looks like it is WAL/CRC |
Date: | 2005-07-01 06:05:44 |
Message-ID: | da2mjv$7hd$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
""Magnus Hagander"" <mha(at)sollentuna(dot)net> writes
>
> FWIW, MSSQL deals with this using "Torn Page Detection". This is off by
> default (no check at all!), but can be abled on a per-database level.
> Note that it only *detects* torn pages. If it finds one, it won't start
> and tell you to recover from backup. It can't automatically recover. I
> would assume this greatly decreases the amount of data you have to
> save...
>
After reading the long discussion on torn page detection and many related
issues in doc/TODO.details/wal, I believe we need carefully analysis what
the sequence of a partial write.
case 1: if a partial write just write some sectors of a 8K page, then it is
ok - assuming we will replay xlog in any ways without comparing page header
LSN and xlog LSN (currently we do not do so);
case 2: if a patial write destroied some old data of a page, which are not
in our xlog, we will worry about this;
So the main issue is case2. If OS could schedule atomic sector-wise write ,
so case2 could never happen?
Regards,
Qingqing
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2005-07-01 06:43:11 | Re: 2PC transaction id |
Previous Message | Junji TERAMOTO | 2005-07-01 06:00:14 | Re: tsearch2 vs core? |