On Fri, 12 Sep 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, here is an Opteron/Itanium patch that might work.
> >
> > [having now read both patches]
> >
> > Assuming that this covers the issues (what other OSes might run on
> > 64-bit machi
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Is the Itanium tas implementation correct?
FWIW, this evening I did a few dozen iterations of "make check" parallel
regression tests on a 4-way Itanium box at Red Hat's Toronto office,
working from CVS-tip sources. No sign of problems. That's not a pr
Manfred Spraul wrote:
Is the Itanium tas implementation correct? I think it should be
xchg4.aqv instead of just xchg4 - as far as I know a normal atomic
exchange is is not a memory barrier on Itanium. At least the Linux
kernel version contains "cmpxchg4.aqv".
Sorry for the noise, I'm wrong:
Ita
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
He is uncomfortable with the port/*.h changes at this point, so it seems
I am going to have to add Itanium/Opteron tests to most of those files.
Why don't you try to put together a proposed patch of that
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, here is an Opteron/Itanium patch that might work.
[having now read both patches]
Assuming that this covers the issues (what other OSes might run on
64-bit machines within 7.4's lifespan?) I think there is little question
that this is the more conser
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, here is an Opteron/Itanium patch that might work.
>
> [having now read both patches]
>
> Assuming that this covers the issues (what other OSes might run on
> 64-bit machines within 7.4's lifespan?) I think there is little questio
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Does this say that Darwin on something other than PPC doesn't have
> > spinlocks? Is that going to hit a spinlock define, or fall through?
>
> It says that darwin.h is broken, and always has been, for non-PPC
> builds. Since there i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Does this say that Darwin on something other than PPC doesn't have
> spinlocks? Is that going to hit a spinlock define, or fall through?
It says that darwin.h is broken, and always has been, for non-PPC
builds. Since there is no non-PPC Darwin (afaik),
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > He is uncomfortable with the port/*.h changes at this point, so it seems
> > I am going to have to add Itanium/Opteron tests to most of those files.
>
> Why don't you try to put together a proposed patch of that kind, and
> then we ca
Bruce Momjian <[EMAIL PROTECTED]> writes:
> He is uncomfortable with the port/*.h changes at this point, so it seems
> I am going to have to add Itanium/Opteron tests to most of those files.
Why don't you try to put together a proposed patch of that kind, and
then we can look to see how big and ug
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > 'K, now, I know we acquire all our shared_buffers on startup now ... do we
> > do the same with semaphores?
>
> Yes.
>
> > If we do acquire at the start, would it not be trivial to add a message to
> > the startup messages, base
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> 'K, now, I know we acquire all our shared_buffers on startup now ... do we
> do the same with semaphores?
Yes.
> If we do acquire at the start, would it not be trivial to add a message to
> the startup messages, based on #_of_semaphores != max_conn
Marc G. Fournier wrote:
>
>
> On Fri, 12 Sep 2003, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > >> If we force people to give a --without-spinlocks config option to build
> > >> that way, then `pg_config --configure' will reveal the dirty deed ...
> >
> > > That's not
On Fri, 12 Sep 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> If we force people to give a --without-spinlocks config option to build
> >> that way, then `pg_config --configure' will reveal the dirty deed ...
>
> > That's not quite what I meant :) Right now, if I un
Bruce Momjian wrote:
> Prompted by confusion over Itanium/Opterion, I have written a patch to
> improve the way we define spinlocks for platforms and cpu's. It
> basically decouples the OS from the CPU spinlock code. In almost all
> cases, the spinlock code cares only about the compiler and CPU,
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> If we force people to give a --without-spinlocks config option to build
>> that way, then `pg_config --configure' will reveal the dirty deed ...
> That's not quite what I meant :) Right now, if I understood what Bruce
> was saying, if someone does
Marc G. Fournier wrote:
>
>
> On Fri, 12 Sep 2003, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > >> Right, though I am not sure people will know _slow_ configuration vs.
> > >> PostgreSQL is slow.
> >
> > > No, but definitely something for those discussion performance
On Fri, 12 Sep 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> Right, though I am not sure people will know _slow_ configuration vs.
> >> PostgreSQL is slow.
>
> > No, but definitely something for those discussion performance to add
> > to their checklist :)
>
> > BTW
Tom Lane wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all=
> > =20
> > care).
>
> Unfixably? Or just a small oversight?
Updated patch now works on Unixware.
--
Bruce Momjian| http://ca
Marc G. Fournier wrote:
> > > >From what I understand, "not working properly" means slow, not broken, no?
> > > Which means ppl could submit a problem report and it could be fixed for
> > > v7.4.1 ... its not so much 'not working properly' as it is 'not optimal
> > > performance' ...
> >
> > Right
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> Right, though I am not sure people will know _slow_ configuration vs.
>> PostgreSQL is slow.
> No, but definitely something for those discussion performance to add
> to their checklist :)
> BTW, post-compile, running system ... how do you check th
On Fri, 12 Sep 2003, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> >
> >
> > On Thu, 11 Sep 2003, Bruce Momjian wrote:
> >
> > > Well, the problem was that we defined HAS_TEST_AND_SET inside the ports.
> > > I guess we could splatter a test for Itanium and Opterion in every port
> > > that co
Marc G. Fournier wrote:
>
> On Thu, 11 Sep 2003, Bruce Momjian wrote:
>
> > I just learned from Larry that Unixware defines intel as i386, not
> > __i386 or __i386__, at least of the native SCO compiler that he uses.
>
> could we put something in the various port files to standardize this? ie.
On Thu, 11 Sep 2003, Bruce Momjian wrote:
> I just learned from Larry that Unixware defines intel as i386, not
> __i386 or __i386__, at least of the native SCO compiler that he uses.
could we put something in the various port files to standardize this? ie.
in unixware.h, add somethinglike:
#if
Marc G. Fournier wrote:
>
>
> On Thu, 11 Sep 2003, Bruce Momjian wrote:
>
> > Well, the problem was that we defined HAS_TEST_AND_SET inside the ports.
> > I guess we could splatter a test for Itanium and Opterion in every port
> > that could possibly use it, but then again, if we fall back to no
--On Friday, September 12, 2003 00:06:49 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
I've already sent a whine-a-gram to the compiler guys at SCO.
Prolly you thought of this already, but: getting them to *add*
an implicit #define of __i386__ should be pl
On Thu, 11 Sep 2003, Bruce Momjian wrote:
> Well, the problem was that we defined HAS_TEST_AND_SET inside the ports.
> I guess we could splatter a test for Itanium and Opterion in every port
> that could possibly use it, but then again, if we fall back to not
> finding it for some reason, we don
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I've already sent a whine-a-gram to the compiler guys at SCO.
Prolly you thought of this already, but: getting them to *add*
an implicit #define of __i386__ should be plenty easy compared
to getting them to *remove* the one for i386. And while I think
--On Friday, September 12, 2003 00:00:43 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
Please, only the first two. Make the Unixware template add __i386__.
Don't add assumptions about valid user-namespace symbols.
that's reasonable. At least until 64-bi
Larry Rosenman <[EMAIL PROTECTED]> writes:
>> Please, only the first two. Make the Unixware template add __i386__.
>> Don't add assumptions about valid user-namespace symbols.
> that's reasonable. At least until 64-bit UnixWare. :-)
Even then, I'd prefer to put the necessary kluge into template
--On Thursday, September 11, 2003 23:42:53 -0400 Tom Lane
<[EMAIL PROTECTED]> wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Looking at the code, I wonder if we already have folks not using
spinlocks, and not even knowing it. I don't think problem reports will
be limited to new platforms.
Ve
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Looking at the code, I wonder if we already have folks not using
> > spinlocks, and not even knowing it. I don't think problem reports will
> > be limited to new platforms.
>
> Very likely --- I heard from someone recently who was tr
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Looking at the code, I wonder if we already have folks not using
> spinlocks, and not even knowing it. I don't think problem reports will
> be limited to new platforms.
Very likely --- I heard from someone recently who was trying to run
HPUX/Itanium. A
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, we could do just the configure warning, then plaster tests into the
> > port files to try to hit all the opteron/itanium cases. I am a little
> > concerned that this might throw up a bunch of problem cases that we will
> > patchi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, we could do just the configure warning, then plaster tests into the
> port files to try to hit all the opteron/itanium cases. I am a little
> concerned that this might throw up a bunch of problem cases that we will
> patching for a while.
Probably
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I guess we could splatter a test for Itanium and Opterion in every port
> > that could possibly use it, but then again, if we fall back to not
> > finding it for some reason, we don't get a report because we silently
> > fall back to s
--On Thursday, September 11, 2003 23:13:54 -0400 Tom Lane
<[EMAIL PROTECTED]> wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
Bruce sent me a copy of the patch, and it BREAKS UnixWare (If
y'all= =20
care).
Unfixably? Or just a small oversight?
I'm actually not worried about platform
Tom Lane wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all=
> > =20
> > care).
>
> Unfixably? Or just a small oversight?
>
> I'm actually not worried about platforms that are actively being tested.
> It's the stuff
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all=
> =20
> care).
Unfixably? Or just a small oversight?
I'm actually not worried about platforms that are actively being tested.
It's the stuff that hasn't been confirmed recent
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I guess we could splatter a test for Itanium and Opterion in every port
> that could possibly use it, but then again, if we fall back to not
> finding it for some reason, we don't get a report because we silently
> fall back to semaphores. That's what ha
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Thu, 11 Sep 2003, Tom Lane wrote:
>> Well, as long as you're prepared to reduce the list of known supported
>> platforms to zero as of 7.4beta3, and issue a fresh call for port reports.
> I didn't think we had done that yet ... had we? called fo
On Thu, 11 Sep 2003, Bruce Momjian wrote:
> Yes, but to throw an error if spinlocks aren't found, we need this
> patch. We would have to test for Opteron in all the platforms that test
> for specific CPU's but don't test for opteron, and might support
> opterion/itanium, but even then, we don't
--On Thursday, September 11, 2003 23:46:56 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Thu, 11 Sep 2003, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The problem with waiting for 7.5 is that we will have no error
> reporting when our non-spinlock code is being execu
Marc G. Fournier wrote:
> > But it seems to me that this is mostly a cosmetic cleanup and therefore
> > not the kind of thing to be doing late in beta. Couldn't we do
> > something that affects only Opteron/Itanium and doesn't take a chance
> > on breaking everything else?
>
> I just went through
On Thu, 11 Sep 2003, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The problem with waiting for 7.5 is that we will have no error reporting
> > when our non-spinlock code is being executed, and with Opteron/Itanium,
> > it seems like a good time to get it working.
>
> Well, as
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The problem with waiting for 7.5 is that we will have no error reporting
> > when our non-spinlock code is being executed, and with Opteron/Itanium,
> > it seems like a good time to get it working.
>
> Well, as long as you're prepared
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The problem with waiting for 7.5 is that we will have no error reporting
> when our non-spinlock code is being executed, and with Opteron/Itanium,
> it seems like a good time to get it working.
Well, as long as you're prepared to reduce the list of known
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Prompted by confusion over Itanium/Opterion, I have written a patch to
> > improve the way we define spinlocks for platforms and cpu's.
>
> The main.c part of the patch strikes me as irrelevant to the claimed
> purpose and unlikely to
This is the email describing the changes in the patch for 7.4.
---
Bruce Momjian wrote:
> Prompted by confusion over Itanium/Opterion, I have written a patch to
> improve the way we define spinlocks for platforms and cpu's.
49 matches
Mail list logo
