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, post-compile,
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 to add
to their
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 doesn't have
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, not
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, based on
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 ugly
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 can look to
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:
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
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 question
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
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
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:
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 proof
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 machines within 7.4's
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 could possibly use
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 this? Or
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, though I am not
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
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:
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
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 long as
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 the
--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 executed,
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
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 for port
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 has me
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 recently
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 that hasn't
--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 platforms
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 semaphores.
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 so
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
patching for a
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. After
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 trying to
--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.
Very
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
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: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
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 not
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:
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.
in
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|
43 matches
Mail list logo
