Re: [HACKERS] Current 6.3 issues - Mailing list pgsql-hackers

From Vadim B. Mikheev
Subject Re: [HACKERS] Current 6.3 issues
Date
Msg-id 34F18207.9EFAB2C2@sable.krasnoyarsk.su
Whole thread Raw
In response to Current 6.3 issues  (Bruce Momjian <maillist@candle.pha.pa.us>)
List 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 by date:

Previous
From: darrenk@insightdist.com (Darren King)
Date:
Subject: Re: [HACKERS] Current 6.3 issues
Next
From: orion.SAPserv.Hamburg.dsh.de!wieck@sapserv.debis.de
Date:
Subject: Re: [HACKERS] Here it is - view permissions]