X-Original-To: pgsql-patches-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 2CE9711F66EA for ; Thu, 27 Apr 2006 21:12:48 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 59205-06 for ; Thu, 27 Apr 2006 21:12:39 -0300 (ADT) X-Greylist: delayed 00:16:50.117221 by SQLgrey- Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 64B7E11F66E6 for ; Thu, 27 Apr 2006 21:12:37 -0300 (ADT) Received: from mail.omniti.com (mail.omniti.com [66.225.209.50]) by svr4.postgresql.org (Postfix) with ESMTP id 67BD45B608B for ; Thu, 27 Apr 2006 23:55:48 +0000 (GMT) Authentication-Results: mail.omniti.com smtp.user=jesus; auth=pass (LOGIN) DomainKey-Status: good X-DomainKeys: Ecelerity dk_sign implementing draft-delany-domainkeys-base-01 DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=test; d=omniti.com; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=kOPhFLObDr6yqJy8HIJkMzR5bo1augdbuOzZFWsRdXH7O33zol6f2HkxRxtylGWU QigVKBrLu6ZqV8/kE8LxaTVCksFX1Z/JO60T4MxM6fXztV9+lM9eU63+b+KXBw21 Received: from ([69.140.132.152:64321] helo=[192.168.218.130]) by mail.omniti.com (ecelerity 2.1.0.1 r(10162)) with ESMTPSA (cipher=AES256-SHA) id 42/96-00410-AF951544 for ; Thu, 27 Apr 2006 19:55:47 -0400 Message-ID: <445159FA.7070206@omniti.com> Date: Thu, 27 Apr 2006 19:55:38 -0400 From: Theo Schlossnagle User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane Cc: Bruce Momjian , josh.berkus@sun.com, robert.lor@sun.com, PostgreSQL-patches Subject: Re: [BUGS] BUG #2401: spinlocks not available on amd64 References: <200604272231.k3RMVYM28488@candle.pha.pa.us> <16483.1146178926@sss.pgh.pa.us> In-Reply-To: <16483.1146178926@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200604/252 X-Sequence-Number: 19524 Tom Lane wrote: >Bruce Momjian writes: > > >>Great, changes attached and applied. I removed the solaris_i386 and >>solaris_x86_64.s files and made just one solaris_x86.s. I updated the >>build system to use the new file, updated the macros, and added some >>documentation on the approach. Thanks. >> >> > >BTW, on the replacement of ldstub with cas: according to what I find in >google, cas does not exist on pre-V9 SPARCs. Are we sure no one uses >sparc v8 chips anymore? Is there any actual advantage to making that >change? > > This is true, and can be addressed with #defines to pull in the old old code. Just to note, you can't run Solaris 10 or any future version of Solaris on sparcv8 either. Sparcv8plus is 3bit sparc code and it does support the cas operation. The instruction cas that operates on a word is more much efficient than the code that it replaced. I'm don't own or have access to any sparc machines old enough to have that issue (even on my guest accounts at my alma mater). If this is a concern, it seems more than reasonable to #elif the case in for that architecture in the sparc assembly file -- being open source, you'll no doubt alienate some dude who thinks its cool to run Postgres on his Sparc ELC. I'd remind everyone that the spinlock stuff is entirely optional at build time. I think it be more elegant approach to discontinue spinlock support on sparcv8 and older sparc architectures and just force them to use heavier weight locking mechanisms. I "accidentally" did this on my Sol10 amd64 box before I realized what the build system did. I also think it immensely useful to replace all of the tas subsystem with cas so that one could reliabily lock these atomics with the process id of the locker. This would allow extremely good diagnostics in the event that a backend process is abruptly teminated while holding a log on that shm segment. If the process ID was in there, it would then be a contition that is both diagnosable and recoverable. I could likely provide the cas bits and pieces to do this stuff on linux/freebsd/mac os x and windows on x86/64 sparcv8plus/sparcv9 and PPC if you think that would be useful. Best regards, Theo