Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....
От | Kevin P. Neal |
---|---|
Тема | Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1.... |
Дата | |
Msg-id | 20000612231745.A24188@tome.neutralgood.org обсуждение исходный текст |
Ответ на | Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1.... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....
|
Список | pgsql-bugs |
On Mon, Jun 12, 2000 at 05:39:55PM -0400, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > That was my guess, though his changes were s_lock related. Seems that is > > an Alpha mess too. > > Yes, it sounds like we will need some help from a certified Alpha guru > to make spinlock code that works reliably on multi-CPU Alphas :-(. If you leave the locking code as it is then PostgreSQL will dump core. If you do not inline the locking code then the registers will not get stomped (gcc bug), and PostgreSQL will function properly enough to initialize itself and make it through a make install. Simple SQL queries work ok, but I never tried anything fancy. I haven't had the time to write up a test case to send to the GCC people. Plus, the other (much larger) set of patches that a Linux/Alpha guy wrote up did the same thing my patches did, but differently (-fno-inline instead of patching the header file to not be __inline__). The other change from me was to change the type for locks to be 32 bits wide instead of 8 bits wide. All Alphas handle 32 bit quantities naturally, but only some can handle 8 or 16 bit quantities. The assembly code tries to do locks with 32 bit quantities, it doesn't make sense to then try to lock an 8 bit quantity. Guys, my patches are not complex. It doesn't take a guru to handle my changes; otherwise I wouldn't have been able to write them. -- Kevin P. Neal http://www.pobox.com/~kpn/ "You know, I think I can hear the machine screaming from here... \ 'help me! hellpp meeee!'" - Heather Flanagan, 14:52:23 Wed Jun 10 1998
В списке pgsql-bugs по дате отправления: