RE: [HACKERS] strange behaviour (bug)

[Hiroshi Inoue]

> -----Original Message----- > From: Mikheev, Vadim [mailto:[EMAIL PROTECTED]] > > > > I'm going to handle btree split but currently there is no way > > > to rollback it - we unlock splitted pages after parent > > > is locked and concurrent backend may update one/both of > > > siblings before we get our locks back. > > > We have to continue with split or could leave parent unchanged > > > and handle "my bits moved..." (ie continue split in another > > > xaction if we found no parent for a page) ... or we could hold > > > locks on all splitted pages till some parent updated without > > > split, but I wouldn't do this. > > > > > > > It seems to me that btree split operations must always be > > rolled forward even in case of abort/crash. DO you have > > other ideas ? > > Yes, it should, but hard to implement, especially for abort case. > So, for the moment, I would proceed with handling "my bits moved...": > no reason to elog(FATAL) here - we can try to insert missed pointers > into parent page(s). WAL will guarantee that btitems moved to right > sibling will not be lost (level consistency), and missing some pointers > in parent level is acceptable - scans will work. > I looked into your XLOG stuff a little. It seems that XLogFileOpen() isn't implemented yet. Would/should XLogFIleOpen() guarantee to open a Relation properly at any time ? Regards. Hiroshi Inoue