Re: pgsql: Improve gist XLOG code to follow the coding
От | Teodor Sigaev |
---|---|
Тема | Re: pgsql: Improve gist XLOG code to follow the coding |
Дата | |
Msg-id | 44314B1C.7090308@sigaev.ru обсуждение исходный текст |
Ответ на | Re: pgsql: Improve gist XLOG code to follow the coding (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
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: teodor@sigaev.ru WWW: http://www.sigaev.ru/
В списке pgsql-committers по дате отправления: