Re: [SQL] Q: spinlock on Alpha? (PG7.0.2)
On Mon, 2 Oct 2000, Tom Lane wrote:
> "Emils Klotins" <[EMAIL PROTECTED]> writes:
> > RedHat Linux 6.2 on Alphaserver DS10 (egcs-1.1.2, glibc-2.1.3,
> > libstdc++-2.9.0).
> > Postgresql-7.0.2 source
>
> > Compiles and installs just fine. However, both the regular initdb and
> > parallel regression testing's initdb stage fails with a core file and
> > message:
>
> > FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.
> > FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.
>
> I was just fooling with PG on a RedHat Alpha box that DEC kindly
> loaned to the project. It looks like the above problem is caused
> by compiler optimization; although src/template/linux_alpha
> optimistically sets CFLAGS=-O2, I had to back off to -O1 to avoid
> that same spinlock complaint, and I couldn't get 7.0.* to pass
> regression tests with anything but -O0. (And even there, there
> were a bunch of failures in the datetime-related tests; it looks
> like our abstime datatype breaks rather badly on this platform.)
To get pgsql running correctly (spinlocks and regression tests) on
Linux/Alpha, one needs the patches off of my web site (as someone already
pointed out in another response to this thread). You can reduce the
optimization levels on the compiler and make some progress, but w/o the
patches, you get nowhere in the end.
Also, some versions of egcs have been known to have problems on
Linux/Alpha, especially when it comes to optimization levels beyond the
default (none). I do know that gcc 2.95.2 (as distributed w/Debian 2.2)
works just fine with -O2. I seem to remember someone mentioning the
compiler with RedHat 6.2 does not work, and they had to upgrade to the
2.95.2 version before the optimization flags were safe.
Of course, there is no release of RH7 for alpha yet (that I know
of), but on the Intel side there are some rumblings that RedHat used a
somewhat broken version of gcc. On top of that, I never quite figured out
the alignment between the egcs and the gcc version numbers (i.e. how does
egcs 1.1.2 relate to gcc 2.95.2?).
I can tell you that with the patches on my web site and the gcc
2.95.2 compiler, everything works great with pgsql. Beyond that, I can not
promise you anything. If anyone wants to test on other compilers, I am
more than glad to help in anyway that I can. And if they report back to me
the results, I will add them to my web page.
> I haven't had time yet to try current sources on that box, but
> I'm optimistic that the new function manager will solve a lot of
> portability problems on Alphas. Still, I don't understand why -O2
> breaks spinlocks --- maybe egcs is misoptimizing around the inline
> assembly code of tas() ?
The last current sources I tested, about a month ago (8/15),
compiled w/o a single problem on my system (Debian 2.2, gcc 2.95.2), w/o
any patches and w/-O2. In other words, the need for special patches for
Linux/Alpha was removed, and now compiles out of the box. Once I get a bit
of time I plan to test more current snapshots, and will of course report
my results.
And yes, the new function manager made about 90% of the 7.0.2
Linux/Alpha patches unneeded. The rest I '#ifdef {linux-alpha}'ed and
submitted a patch (quite short if I remember), which was accepted. Even
patched the regression tests results for geometry to match the Linux/Alpha
output (which actually matched a few other platforms as well). So now even
all regression tests as well. :)
As for the spinlock, it is a compiler problem. At one time it had
non-local labels and therefore could not be inlined (i.e. multiple labels
w/the same name resulteD), but I fixed it by replacing all the labels with
local ones about a year or more ago. Compilers on Linux/Alpha have a
history of misbehaving when it came to the more aggressive optimization.
Only recently has most of the wrinkles been ironed out.
That is my two cents, hope they are of use. TTYL.
---
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---
Re: [SQL] Q: spinlock on Alpha? (PG7.0.2) - solved
On Tue, 3 Oct 2000, Emils Klotins wrote: > From: Fabrice Scemama <[EMAIL PROTECTED]> > > Try this: > > http://www.rkirkpat.net/software/ > > > parallel regression testing's initdb stage fails with a core file and > > > message: > > > > > > FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting. > > > FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting. > > > > > Thanks, it worked! You are welcome... Some one beat me to directing you to my own site. :) > Now everything works fine and the only regression tests that fail > are > tinterval > abstime > geometry > > I wonder if I might have any problems because of those? The failure with geometry is an off by one error in the nth decimal place, in other words harmless (providing you are not calculating trajectories for an interplanetary space mission :). The other two should not have failed. Have you tried diffing the results against the expected results? Often times timezones being misconfigured can cause strange problems. If there is nothing obvious in the resulting diffs (i.e. nothing that can be traced to a local problem), please email the regression results to me (an attached .tgz is fine), and I will take a look. TTYL. --- | "For to me to live is Christ, and to die is gain."| | --- Philippians 1:21 (KJV) | --- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---
[SQL] Sequences do not obey transactions...
Either I am missing something or I found a bug in PostgreSQL. Hopefully it is the former. :) Simply, I am trying to use a sequence to generate unique id numbers for a table. Now, a number of the fields in this table have 'check constraints'. What happens, is if I attempt to insert a row into the table that fails to meet the constraints and is rejected, the sequence is still incremented. Therefore, for each failed insert, a hole results in my id number sequence. While this is not fatal, it is very annoying. I even tried wrapping a BEGIN / END around a failing insert and the sequence still incremented. It appears that whenever the 'nextval' function is called, no matter where, in a failing insert, inside an aborted transaction, etc..., the changes it makes to the sequence are permanent. So is this supposed to be this way, or did I stumble across a bug? If the former, would some one please explain why this is this way (and possibly add it to the documenation). Thanks. PS. The mailing list search engines on the pgsql web site are broken. They either find nothing, no matter what search terms one enters, or complain about not being able to find the needed tables (relations). --- | "For to me to live is Christ, and to die is gain."| |--- Philippians 1:21 (KJV) | ------- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---
[SQL] Re: [GENERAL] Sequences do not obey transactions...
On Wed, 21 Jun 2000, Haroldo Stenger wrote: > This issue has been asked & answered MANY times, once a week perhaps. I'll copy > here what a folk answered once Hmm.. Then if the email archive searchs on the web site had been working I would not have had to was the list's time. As for the comments by people that pgsql's sequence behavior is well documented, please tell me where! I have looked through the HTML does and the FAQ that comes with Pgsql 7.0.2 and found no mention of it. > "You can't. Sequences are not designed for continuity, they are designed for > uniqueness. Now that I think about it (again w/other people's explainations taken into account) pgsql's behavior now makes sense to me. I was just looking for a continuous sequence of unique numbers and thought a sequence might be handy. Guess not. :( Thanks for everyone's explaination. > Haroldo Stenger wrote: > > And I add one of my own: It is not really necessary to have continuity in nearly > > all apps. Your question is valid anyhow, but ask yourself: How does Oracle > > resolve this? How would I program it myself by hand? And there you'll understand > > the issue deeply. > > How funny it is to quote myself :9 I'd like to add this: When one has to number > paper forms (invoices for instance), one must be careful about holes in > sequences. What I do, is to have two sequences. One for the user, and one for > the system. When the user has confirmed all her data, I'll COPY to another table > the data, which NOW doesn't have a chance to cancel. Well, not so sure, but 99% > of aborts, are user aborts. So this may help. That is similar to what I was attempting to do. I am making an inventory database where each piece of computer equipment has a unique number assigned to it. A sequence would save me having to figure out what number was next. But if it had holes in the sequence, then I would end up wasting the sequential labels I had already printed. :( Given my situtation, I think I will just use the label sheet to tell me which number is next and enter it in from there. Low-tech, but should work. :) > Note to Bruce (or current FAQ mantainer): Please, add both the answer to the > very question, and this addition of my own to the FAQ. I would have loved to > find it somewhere, when I didn't know what to do. Yes, please do. I always search the documentation and email list archives (if available) before asking a question. Guess in this case I hit a question that fell through the cracks before making it into the FAQ. Once again, thanks for everyone's help. --- | "For to me to live is Christ, and to die is gain."| | --- Philippians 1:21 (KJV) | --- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---
