Re: [HACKERS] Current 6.3 issues
Vadim B. Mikheev <vadim@sable.krasnoyarsk.su>
From: "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>
To: PostgreSQL-development <hackers@postgreSQL.org>
Cc: tih@Hamartun.Priv.NO
Date: 1998-02-23T14:04:55Z
Lists: 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