Tom Lane wrote:
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).
Hm. The mentioned piece of code executes only for incomplete inserts.
It is a part of gistContinueInsert() called from gist_xlog_cleanup()...
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.
I was reading nbtree code and noticed, that new (just created) page fills "in
place", without START_CRIT_SECTION. As I understand, new page we can easy change
while it hasn't any link from other tree/pages.
gistSplit fills shadow (returned by PageGetTempPage()) of original page, so,
in that case, splitSplit can postpone PageRestoreTempPage() to caller. I can
make changes of gistSplit() on this week.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
