Skip site navigation (1) Skip section navigation (2)

Re: stuck spinlock

From: Peter Schindler <pschindler(at)synchronicity(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pg-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: stuck spinlock
Date: 2001-02-28 11:05:04
Message-ID: B0021317079@tellurian.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Judging from the line number, this is in CreateCheckPoint.  I'm
> betting that your platform (Solaris 2.7, you said?) has the same odd
> behavior that I discovered a couple days ago on HPUX: a select with
> a delay of tv_sec = 0, tv_usec = 1000000 doesn't delay 1 second like
> a reasonable person would expect, but fails instantly with EINVAL.
After I finally understood what you meant, this behavior looks somehow
reasonable to me as its a struct, but I must admit, that I don't have 
to much knowledge in this area.

Anyway, after further thoughts I was curious about this odd behavior on
the different platforms and I used your previously posted program, extended
it a little bit and run it on all platforms I could get a hold of.
Please have a look at the extracted log and comments below about the different 
platforms. It seems, that this functions a "good" example of a really 
incompatible implementation across platforms, even within the same 
across different versions of the OSs.
Happy wondering ;-)


> In short: please try the latest nightly snapshot (this fix is since
> beta5, unfortunately) and let me know if you still see a problem.
I did and I didn't get the error yet, but didn't run as many jobs either.
If I get the error again, I'll post it.

Thanks for your help,
Peter

=====

Attachment: seltest.txt
Description: text/plain (9.1 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2001-02-28 13:00:05
Subject: Re: Idea for reducing planning time
Previous:From: Matthew KirkwoodDate: 2001-02-28 10:32:56
Subject: Re: mmap for zeroing WAL log

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group