Re: [HACKERS] Current 6.3 issues
От | Vadim B. Mikheev |
---|---|
Тема | Re: [HACKERS] Current 6.3 issues |
Дата | |
Msg-id | 34F18207.9EFAB2C2@sable.krasnoyarsk.su обсуждение исходный текст |
Ответ на | Current 6.3 issues (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
> Check select_views regression test Second query is replaced -> there shouldn't be differences any more... > 'Can not write block blind' error on createdb and regression collision(Vadim) New bug was introduced in mdblindwrt(): backend tried to use current database path when writing data for another data base => path was invalid => elog(ERROR). I fixed this: now backend uses GetRawDatabaseInfo() to get real path for given data base, BUT I don't like this way: GetRawDatabaseInfo() reads pg_database to get path and this is really bad for performance! Keeping in mind implementation of TABLESPACEs in _near_ future we have to either use symlinks to give backend simple and fast way to constract full path to a relation or store full path in buffer header. Shared memory is critical resource but nevertheless I prefer the second way. Now about hanging another backends after 'blind' error. This is very old bug in buffer manager: before doing blind write backend locks buffer for IO using local spinlock of this buffer, but elog(ERROR) doesn't releases spinlocks of this type! I tried to fix this too but decided that there is not enough time to do this now: there are another "bad places" in bufmgr. Re-visiting of bufmgr was in my plans after 6.0, but ... hope to do this for 6.4. Vadim
В списке pgsql-hackers по дате отправления: