Alfred Perlstein <[EMAIL PROTECTED]> writes:
> One trick that may help is calling sched_yield(2) on a lock miss,
> it's a POSIX call and quite new so you'd need a 'configure' test
> for it.
The author of the current s_lock code seems to have thought that
select() with a zero delay would do the eq
On 28 Dec 2000 at 23:08 (-0500), Tom Lane wrote:
| > after fresh CVS update: geometry, float8, and oid are still failing,
|
| You're running this on DEC's cc, right? Geometry and float8 are a
| matter of fixing the expected output, I think. I'm surprised that the
| OID test is failing for you -
* Tom Lane <[EMAIL PROTECTED]> [001228 14:25] wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > I wonder about the advisability of using spinlocks in user-level code
> > which might be swapped out any time.
>
> The reason we use spinlocks is that we expect the lock to succeed (not
> block) t
[EMAIL PROTECTED] (Nathan Myers) writes:
> On Thu, Dec 28, 2000 at 05:12:22PM -0500, Tom Lane wrote:
>> The reason we use spinlocks is that we expect the lock to succeed (not
>> block) the majority of the time, and we want the code to fall through
>> as quickly as possible in that case. In partic
> after fresh CVS update: geometry, float8, and oid are still failing,
You're running this on DEC's cc, right? Geometry and float8 are a
matter of fixing the expected output, I think. I'm surprised that the
OID test is failing for you --- it passes for me on that Debian box.
Could you step thro
On 28 Dec 2000 at 17:40 (-0500), Tom Lane wrote:
| Okay ... I guess the LOCK_LONG macros are our best shot. Here is a
| proposed new Alpha section for s_lock.h. Would you try it and let me
| know how it works for you?
|
| Note that this will NOT fix the CreateCheckPoint shutdown error; don't
|
On Thu, Dec 28, 2000 at 05:26:23PM -0600, Dominic J. Eidson wrote:
> On Thu, 28 Dec 2000, Nathan Myers wrote:
>
> > The code is based on some odd assumptions. A select() with 0 delay
> > returns immediately unless there is an interrupt during its (very short!)
>
> If you look closely, it's a
On Thu, 28 Dec 2000, Nathan Myers wrote:
> The code is based on some odd assumptions. A select() with 0 delay
> returns immediately unless there is an interrupt during its (very short!)
If you look closely, it's a select with a 2 second timeout.
>>> { 2, 0 }
--
Dominic J. Eidson
On Thu, Dec 28, 2000 at 05:12:22PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > I wonder about the advisability of using spinlocks in user-level code
> > which might be swapped out any time.
>
> The reason we use spinlocks is that we expect the lock to succeed (not
> blo
[EMAIL PROTECTED] (Nathan Myers) writes:
> I wonder about the advisability of using spinlocks in user-level code
> which might be swapped out any time.
The reason we use spinlocks is that we expect the lock to succeed (not
block) the majority of the time, and we want the code to fall through
as
Ok.
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 28, 2000 2:07 PM
> To: Mikheev, Vadim
> Cc: [EMAIL PROTECTED]
> Subject: Re: Assuming that TAS() will succeed the first time
> is verboten
>
>
>
> "Mikheev, Vadim" <[EMAIL PROTECTED]> write
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Anyway I don't object if it bothers you -:)
> But please do not use S_LOCK - as you see WAL code try to do other
> things if slock of "primary interest" is busy.
In some places, yes. But I also saw a number of places where S_LOCK is
sufficient, and
> The bottom line turns out to be that on the Alpha hardware, it is
> possible for TAS() to fail even when the lock is initially zero,
> because that hardware's locking protocol will fail to acquire the
> lock if the ldq_l/stq_c sequence is interrupted. TAS() *must* be
> called in a retry loop on
On Thu, Dec 28, 2000 at 03:54:50PM -0500, Tom Lane wrote:
> I have been digging into the observed failure
>
> FATAL: Checkpoint lock is busy while data base is shutting down
>
> on some Alpha machines. It apparently doesn't happen on all Alphas,
> but it's quite reproducible on some of them.
>
Brent Verner <[EMAIL PROTECTED]> writes:
> what have I stumbled into :). 'damnit Jim!, I'm just a perl hacker.'
I've found an online version of the AXP Architecture Handbook at
ftp://ftp.netbsd.org/pub/NetBSD/misc/dec-docs/index.html
in particular the file ec-qd2ka-te.ps.gz listed near the top
On 28 Dec 2000 at 12:41 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > I see this with the version of TAS() that you recently suggested, but not
| > with either of the versions I'd hacked up.
|
| Hm. Your second version might incorrectly appear to work because it's
| no
I have been digging into the observed failure
FATAL: Checkpoint lock is busy while data base is shutting down
on some Alpha machines. It apparently doesn't happen on all Alphas,
but it's quite reproducible on some of them.
The bottom line turns out to be that on the Alpha hardware, it is
possi
are receiving a kingdom that cannot be
shaken, let us be thankful, and so worship God acceptably with
reverence and awe, for our "God is a consuming fire."
-- Hebrews 12:28-29
http://www.heartlight.org/cgi-shl/todaysverse.cgi?da
Tom Lane writes:
> >> FWIW, I'm running GNU Make version 3.79.1, which is the latest release
> >> last I checked.
>
> > ... but not necessarily the best. :-(
>
> What do you recommend? IIRC, I updated to this version because it fixed
> a bug that was biting me in gmake 3.78.1.
3.76.1 works best
Brent Verner <[EMAIL PROTECTED]> writes:
> I see this with the version of TAS() that you recently suggested, but not
> with either of the versions I'd hacked up.
Hm. Your second version might incorrectly appear to work because it's
not checking for stq_c failure. The first one loops until it s
On 28 Dec 2000 at 10:48 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > another loop-free version of TAS that /seems/ to work as desired.
|
| Since it doesn't check to see if the stq_c succeeded, it can't possibly
| be right...
right, I just realized that while composing
Adriaan Joubert <[EMAIL PROTECTED]> writes:
> For Tru64 there are macros in /usr/include/alpha/builtins.h
> which do the job.
It would be interesting to see the assembly code that those macros
expand to.
> Doing this in assembler is totally non-trivial, as most versions are
> only liable to work
On 28 Dec 2000 at 17:03 (+0200), Adriaan Joubert wrote:
| Hi,
|
| I missed the beginning of this thread. Are you doing this for Tru64 or
| for Linux? For Tru64 there are macros in /usr/include/alpha/builtins.h
| which do the job.
gcc + Tru64, since gcc-2.95.2 doesn't implement the builtins
Brent Verner <[EMAIL PROTECTED]> writes:
> another loop-free version of TAS that /seems/ to work as desired.
Since it doesn't check to see if the stq_c succeeded, it can't possibly
be right...
> WRT to your seeing the shutdown lock failure, what are you doing to
> provoke this bug?
"pg_ctl stop
Hi,
I missed the beginning of this thread. Are you doing this for Tru64 or
for Linux? For Tru64 there are macros in /usr/include/alpha/builtins.h
which do the job.
Doing this in assembler is totally non-trivial, as most versions are
only liable to work on single-processor machines and no
On 27 Dec 2000 at 21:37 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > This is a revised patch that I sent earlier to allow building
| > pg-7.1 with gcc as well as DEC's cc. I've had good results with this
| > applied. Could some other Alpha users try this out. Even bett
just committed. initdb is required.
*I didn't do any serious tests yet*, simple regression only.
I'll run more tests in the next couple of days.
Plase, help with this.
Vadim
> > There is something busted in the snapshots, that leads to a wrong
> > configure file. The file is equal to configure.in (not autoconf'ed).
> > First noticed shortly before Christmas.
>
> Last week I tried to do a "make clean" in some subdirectory that's
> not cleaned by a toplevel clean -- I
Tom Lane wrote:
>"Oliver Elphick" <[EMAIL PROTECTED]> writes:
>>> FATAL 2: Checkpoint lock is busy while data base is shutting down
>> It's not just on Alpha; I've seen that on my i386 Linux system.
>FWIW, I do *not* see this behavior on HPUX. It seems perfectly
>reproducible on the
29 matches
Mail list logo
