| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Cc: | pgsql-committers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
| Subject: | Re: pgsql: Improve gist XLOG code to follow the coding |
| Date: | 2006-04-03 13:37:14 |
| Message-ID: | 7342.1144071434@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
>> Hmm. That probably needs to be redesigned then.
> Don't understand. Root will be fully regenerated and filled with invalid tuples.
Well, ISTM that if complete replay of the WAL sequence yields an invalid
index, then you've not got an adequate design for the WAL data. Special
recovery actions really should only be needed if the WAL log is
incomplete (ie, it ends in the middle of a page-split sequence).
> I see, there is a problem with gistSplit: it can generate more than 3 pages
> (three - is a limit of XLogInsert) in a case of bad user's picksplit method...
I think we are OK on that, actually, because the page-split WAL record
is designed to rewrite all of the pages completely. Only pages that are
going to be incrementally updated need to be exposed to XLogInsert.
So the root-page case in page-update is the only one that seems inadequate.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Teodor Sigaev | 2006-04-03 13:44:33 | pgsql: Eliminate ajust scan code. |
| Previous Message | Teodor Sigaev | 2006-04-03 10:45:28 | pgsql: Detoast query in g_intbig_consistent and copy query in |