Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6 |
Дата | |
Msg-id | 350DF216.C8E3E3C7@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6 (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6
Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6 |
Список | pgsql-hackers |
> > Can you submit an appropriate patch that can be included in the > > mega-patch to be created on Sunday? > > Just a warning that this is not going to be easy. We have OS-specific > code for spinlocks in include/storage/s_lock.h and > backend/storage/buffer/s_lock.c. So each S_LOCK macro call has to > have its test-and-set logic de-coupled with its > while-lock-fail-try-again logic. > Most of them are easy, but some like VAX: > > #define S_LOCK(addr) __asm__("1: bbssi $0,(%0),1b": :"r"(addr)) > > are hard to de-couple. Now, I did not know we supported NetBSD on > VAX. Does it work, anyone? Can I remove it? NetBSD on VAX in on our supported list, and was verified for v6.3 by Tom Helbekkmo. > This is going to be pretty tough to test on every platform we support, > so if it is done now, it will have to be done carefully. Is this behavior in v6.2.x? In any case, if it is anything but minimally trivial, it should be given a test on every supported platform, since it hits the heart of the platform-specific code, doesn't it? Seems like it should be put into the CVS tree and shaken out until the next release... - Tom
В списке pgsql-hackers по дате отправления: