Обсуждение: Why need XLogReadBuffer have the paramter "init"?
Cann't we remove this param? We can rewrite like this: 1.XLogReadBuffer: * remove init; * everytime we cann't read a block, just "log_invalid_page" it, and return InvalidBuffer; 2.Also rewrite all functions calling XLogReadBuffer with "init=true": skip current block if XLogReadBuffer return InvalidBuffer. e.g. replace Assert(BufferIsValid(buffer)) with: * if (!BufferIsValid(buffer)) return; Is there any harm? Another question: if oid counter wraparound occured, and one relfilenode was reused, e.g. see the following sequece: 1. Once there was a rel with oid XXXX; 2. Then it's dropped; 3. Then OIDs counter wraparound occured; 4. Another rel was created, and reused oid XXXX; If there's no checkpoint since the first step, and system crashes after step 4, is it possible that the new rel's data be destroyed?
"Jacky Leng" <lengjianquan@163.com> writes:
> Cann't we remove this param?
No.
> We can rewrite like this:
> 1.XLogReadBuffer:
> * remove init;
> * everytime we cann't read a block, just "log_invalid_page" it, and return
> InvalidBuffer;
Your proposal degrades the robustness of the system by turning non-error
cases into errors. If the caller is able to rewrite the page fully, we
should not report an error when it's not available to read.
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> д���ʼ� news:15998.1176303488@sss.pgh.pa.us... > "Jacky Leng" <lengjianquan@163.com> writes: > > Cann't we remove this param? > > No. > > > We can rewrite like this: > > 1.XLogReadBuffer: > > * remove init; > > * everytime we cann't read a block, just "log_invalid_page" it, and return > > InvalidBuffer; > > Your proposal degrades the robustness of the system by turning non-error > cases into errors. If the caller is able to rewrite the page fully, we > should not report an error when it's not available to read. Oh, I see, but how about my second question, is it possible? If it happens: 1. the second rel's pages' lsn surely is lager than xlog records of the first rel; 2. so it's possible some xlog record are not redoed; 3. but those pages that can be rewrite fully are rewrited unconditionaly, If I do a PITR recovery now, is there any trouble?----The file contains both old rels'data and new rel's. Am I wrong?
Oh, I am wrong! "Jacky Leng" <lengjianquan@163.com> д���ʼ� news:evk3gj$i94$1@news.hub.org... > > "Tom Lane" <tgl@sss.pgh.pa.us> д���ʼ� > news:15998.1176303488@sss.pgh.pa.us... > > "Jacky Leng" <lengjianquan@163.com> writes: > > > Cann't we remove this param? > > > > No. > > > > > We can rewrite like this: > > > 1.XLogReadBuffer: > > > * remove init; > > > * everytime we cann't read a block, just "log_invalid_page" it, and > return > > > InvalidBuffer; > > > > Your proposal degrades the robustness of the system by turning non-error > > cases into errors. If the caller is able to rewrite the page fully, we > > should not report an error when it's not available to read. > > Oh, I see, but how about my second question, is it possible? > If it happens: > 1. the second rel's pages' lsn surely is lager than xlog records of the > first rel; > 2. so it's possible some xlog record are not redoed; > 3. but those pages that can be rewrite fully are rewrited unconditionaly, > > If I do a PITR recovery now, is there any trouble?----The file contains both > old rels'data and new rel's. > > > Am I wrong? > >