[SQL] currval
Hi,
I'm executing the following statements in series.
insert into [tablename] values('a', 'b', 'c');
select currval('serial');
serial being the default index on [tablename]
The statement works fine from the command line, however, when executing via
jdbc, I'm getting no results back (null pointer).
Has anyone experienced this and have a solution?
Regards,
Craig May
Enth Dimension
http://www.enthdimension.com.au
Re: [SQL] question on diagnostics
I can confirm that this is now fixed, and will appear in 7.1 when it is released. test=> select * from a natural inner join b natural inner join c; a --- 1 (1 row) > > > oh, btw this select refused to use an SQL natural join among the 3 > > > relations - the server gives up and disconnects without warning. > > > > That sounds like a garden-variety bug. I'd be willing to look at it > > if I had a complete example to follow, but I don't want to try to > > reverse-engineer your table definitions... > > a join with 3 tables never seems to work: > > test=# create table a(a int); > CREATE > test=# create table b(a int); > CREATE > test=# create table c(a int); > CREATE > test=# insert into a values (1); > INSERT 23734 1 > test=# insert into b values (1); > INSERT 23744 1 > test=# insert into c values (1); > INSERT 23736 1 > test=# select * > test-# from a, b, c > test-# where a.a = b.a AND > test-# b.a = c.a; > a | a | a > ---+---+--- > 1 | 1 | 1 > (1 row) > test=# select * from a natural inner join b natural inner join c; > pqReadData() -- backend closed the channel unexpectedly. > This probably means the backend terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > > > alex > > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[SQL] Q: spinlock on Alpha? (PG7.0.2)
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 fished around in the mailing lists and as I understand there has been some problems with spinlock on Alpha, which have been resolved? Any ideas what could I check/do about that greatly appreciated ( especially as I need to move the production server to alpha ASAP :(( )! TIA, Emils
Re: [SQL] Q: spinlock on Alpha? (PG7.0.2)
"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.) 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() ? regards, tom lane
