Re: [BUGS] currval and nextval in 7.3.4
Hello,
Quoting Keith Marr <[EMAIL PROTECTED]>:
> Hi,
>
> I recently installed 7.3.4 (complete install from scratch) and both 'select
>
> nextval('my_seq') from my_table' and 'select currval('my_seq') from my_table'
>
> return a number of rows equal to the number of rows in the table.
>
> The sequence was created with a SERIAL type if that helps.
> In 'psql' the results look like this.
>
I think "select nextval('my_seq');" is what you want to do.
> my_db=# select nextval('my_seq') from my_table;
> nextval
> -
>6
>7
>8
>9
> (4 rows)
>
Idem with select currval('my_seq');
> my_db=# select currval('my_seq') from my_table;
> currval
> -
>9
>9
>9
>9
> (4 rows)
>
> I get the same results using the JDBC driver so it's not a psql problem.
>
> Any thoughts out there?
>
>
It is not a bug (or undocumented feature as some software vendor would say).
Your queries are syntaxically correct SQL requests, but they are not what you
really want.
(If you try "select now() from my_table;", it will also return 4 rows.)
Regards
J6M
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] PostgreSQL Patch: Test-and-set routine for HP-UX (IA-64)
Download current CVS and try that, or 7.4beta5. --- ViSolve Open Source Team wrote: > Subject: PostgreSQL Patch: Test-and-set routine for HP-UX (IA-64) > > > Hello, > > The attached patch provides a test-and-set routine for PostgreSQL for HP-UX > 11iV2 for the Intel Itanium architecture (known to the PostgreSQL code as > IA-64). There are actually two issues: > > 1. There is currently no tas (test-and-set) routine for HP-UX IA-64 in the > s_lock.h header file. > 2. In HP-UX IA-64, the suffix of shared libraries is ".so", but PostgreSQL > generates a ".sl" suffix. > > The attached patch fixes both issues. The bug template (also attached) > contains the details. > > We (ViSolve) are a group that works closely with HP on their OpenSource > initiative. We would really appreciate a timely inclusion of this patch > into mainstream PostgreSQL. > > thanks > ViSolve OpenSource Team (for HP) [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] ISM shared memory on solaris
I hope this is the right place to send this.. the FAQ in the distribution mentions http://www.PostgreSQL.org/bugs/bugs.php, which doesn't work. We've found that postgresql wasn't using ISM shared memory on solaris, which theoretically would cost performance. The root cause in our case was that the "solaris" define is not defined by our compilers or by postgresql itself. The patch below simple has it check SHM_SHARE_MMU instead, which should work fine. I verified (with 'pmap') that the database is now using ISM on its shared memory, after this patch was applied. --Josh --- sysv_shmem.c.orig 2002-09-04 13:31:24.0 -0700 +++ sysv_shmem.c2003-10-23 12:52:26.756765000 -0700 @@ -143,7 +143,7 @@ on_shmem_exit(IpcMemoryDelete, Int32GetDatum(shmid)); /* OK, should be able to attach to the segment */ -#if defined(solaris) && defined(__sparc__) +#if defined(SHM_SHARE_MMU) && defined(__sparc__) /* use intimate shared memory on SPARC Solaris */ memAddress = shmat(shmid, 0, SHM_SHARE_MMU); #else @@ -323,8 +323,8 @@ shmid = shmget(NextShmemSegID, sizeof(PGShmemHeader), 0); if (shmid < 0) continue; /* failed: must be some other app's */ - -#if defined(solaris) && defined(__sparc__) + +#if defined(SHM_SHARE_MMU) && defined(__sparc__) /* use intimate shared memory on SPARC Solaris */ memAddress = shmat(shmid, 0, SHM_SHARE_MMU); #else ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] ISM shared memory on solaris
Yikes! We thought we were already using ISM on Solaris. Would you test the attached patch? It uses _solaris_ rather than SHM_SHARE_MMU in the define test. Does that work too? --- Josh Wilmes wrote: > I hope this is the right place to send this.. the FAQ in the > distribution mentions http://www.PostgreSQL.org/bugs/bugs.php, which > doesn't work. > > We've found that postgresql wasn't using ISM shared memory on solaris, > which theoretically would cost performance. The root cause in our case > was that the "solaris" define is not defined by our compilers or by > postgresql itself. > > The patch below simple has it check SHM_SHARE_MMU instead, which should > work fine. I verified (with 'pmap') that the database is now using ISM > on its shared memory, after this patch was applied. > > --Josh > > > > --- sysv_shmem.c.orig 2002-09-04 13:31:24.0 -0700 > +++ sysv_shmem.c2003-10-23 12:52:26.756765000 -0700 > @@ -143,7 +143,7 @@ > on_shmem_exit(IpcMemoryDelete, Int32GetDatum(shmid)); > > /* OK, should be able to attach to the segment */ > -#if defined(solaris) && defined(__sparc__) > +#if defined(SHM_SHARE_MMU) && defined(__sparc__) > /* use intimate shared memory on SPARC Solaris */ > memAddress = shmat(shmid, 0, SHM_SHARE_MMU); > #else > @@ -323,8 +323,8 @@ > shmid = shmget(NextShmemSegID, sizeof(PGShmemHeader), 0); > if (shmid < 0) > continue; /* failed: must > be some other app's */ > - > -#if defined(solaris) && defined(__sparc__) > + > +#if defined(SHM_SHARE_MMU) && defined(__sparc__) > /* use intimate shared memory on SPARC Solaris */ > memAddress = shmat(shmid, 0, SHM_SHARE_MMU); > #else > > > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/backend/port/sysv_shmem.c === RCS file: /cvsroot/pgsql-server/src/backend/port/sysv_shmem.c,v retrieving revision 1.21 diff -c -c -r1.21 sysv_shmem.c *** src/backend/port/sysv_shmem.c 13 Oct 2003 22:47:15 - 1.21 --- src/backend/port/sysv_shmem.c 24 Oct 2003 15:46:03 - *** *** 133,139 on_shmem_exit(IpcMemoryDelete, Int32GetDatum(shmid)); /* OK, should be able to attach to the segment */ ! #if defined(solaris) && defined(__sparc__) /* use intimate shared memory on SPARC Solaris */ memAddress = shmat(shmid, 0, SHM_SHARE_MMU); #else --- 133,139 on_shmem_exit(IpcMemoryDelete, Int32GetDatum(shmid)); /* OK, should be able to attach to the segment */ ! #if defined(__solaris__) && defined(__sparc__) /* use intimate shared memory on SPARC Solaris */ memAddress = shmat(shmid, 0, SHM_SHARE_MMU); #else *** *** 352,358 hdr = (PGShmemHeader *) shmat(*shmid, UsedShmemSegAddr, ! #if defined(solaris) && defined(__sparc__) /* use intimate shared memory on Solaris */ SHM_SHARE_MMU #else --- 352,358 hdr = (PGShmemHeader *) shmat(*shmid, UsedShmemSegAddr, ! #if defined(__solaris__) && defined(__sparc__) /* use intimate shared memory on Solaris */ SHM_SHARE_MMU #else ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] ISM shared memory on solaris
Josh Wilmes wrote: > Nope, __solaris__ is not defined on our system either. I thought our configure defined __portname__ for every platform, but I don't see that anywhere, so it seems we rely on the compiler to supply defines for the cpu and OS. Does src/tools/ccsym show you your defines? I would like to have something that identifies Solaris rather than something that checks for ISM so that if the ISM define isn't found, we throw an error and we hear about it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] ISM shared memory on solaris
Bruce Momjian wrote: Josh Wilmes wrote: Nope, __solaris__ is not defined on our system either. I thought our configure defined __portname__ for every platform, but I don't see that anywhere, so it seems we rely on the compiler to supply defines for the cpu and OS. Does src/tools/ccsym show you your defines? I would like to have something that identifies Solaris rather than something that checks for ISM so that if the ISM define isn't found, we throw an error and we hear about it. That would be preferable- i didn't know what was safe to assume would always be defined. ccsym is pretty neat. Here's what it shows (gcc) __GNUC__=2 __GNUC_MINOR__=95 sparc sun unix __svr4__ __SVR4 __sparc__ __sun__ __unix__ __svr4__ __SVR4 __sparc __sun __unix system=unix system=svr4 __GCC_NEW_VARARGS__ cpu=sparc machine=sparc ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] ISM shared memory on solaris
Nope, __solaris__ is not defined on our system either.
--Josh
Bruce Momjian wrote:
Yikes! We thought we were already using ISM on Solaris.
Would you test the attached patch? It uses _solaris_ rather than
SHM_SHARE_MMU in the define test. Does that work too?
---
Josh Wilmes wrote:
I hope this is the right place to send this.. the FAQ in the
distribution mentions http://www.PostgreSQL.org/bugs/bugs.php, which
doesn't work.
We've found that postgresql wasn't using ISM shared memory on solaris,
which theoretically would cost performance. The root cause in our case
was that the "solaris" define is not defined by our compilers or by
postgresql itself.
The patch below simple has it check SHM_SHARE_MMU instead, which should
work fine. I verified (with 'pmap') that the database is now using ISM
on its shared memory, after this patch was applied.
--Josh
--- sysv_shmem.c.orig 2002-09-04 13:31:24.0 -0700
+++ sysv_shmem.c2003-10-23 12:52:26.756765000 -0700
@@ -143,7 +143,7 @@
on_shmem_exit(IpcMemoryDelete, Int32GetDatum(shmid));
/* OK, should be able to attach to the segment */
-#if defined(solaris) && defined(__sparc__)
+#if defined(SHM_SHARE_MMU) && defined(__sparc__)
/* use intimate shared memory on SPARC Solaris */
memAddress = shmat(shmid, 0, SHM_SHARE_MMU);
#else
@@ -323,8 +323,8 @@
shmid = shmget(NextShmemSegID, sizeof(PGShmemHeader), 0);
if (shmid < 0)
continue; /* failed: must
be some other app's */
-
-#if defined(solaris) && defined(__sparc__)
+
+#if defined(SHM_SHARE_MMU) && defined(__sparc__)
/* use intimate shared memory on SPARC Solaris */
memAddress = shmat(shmid, 0, SHM_SHARE_MMU);
#else
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Index: src/backend/port/sysv_shmem.c
===
RCS file: /cvsroot/pgsql-server/src/backend/port/sysv_shmem.c,v
retrieving revision 1.21
diff -c -c -r1.21 sysv_shmem.c
*** src/backend/port/sysv_shmem.c 13 Oct 2003 22:47:15 - 1.21
--- src/backend/port/sysv_shmem.c 24 Oct 2003 15:46:03 -
***
*** 133,139
on_shmem_exit(IpcMemoryDelete, Int32GetDatum(shmid));
/* OK, should be able to attach to the segment */
! #if defined(solaris) && defined(__sparc__)
/* use intimate shared memory on SPARC Solaris */
memAddress = shmat(shmid, 0, SHM_SHARE_MMU);
#else
--- 133,139
on_shmem_exit(IpcMemoryDelete, Int32GetDatum(shmid));
/* OK, should be able to attach to the segment */
! #if defined(__solaris__) && defined(__sparc__)
/* use intimate shared memory on SPARC Solaris */
memAddress = shmat(shmid, 0, SHM_SHARE_MMU);
#else
***
*** 352,358
hdr = (PGShmemHeader *) shmat(*shmid,
UsedShmemSegAddr,
! #if defined(solaris) && defined(__sparc__)
/* use intimate shared memory on Solaris */
SHM_SHARE_MMU
#else
--- 352,358
hdr = (PGShmemHeader *) shmat(*shmid,
UsedShmemSegAddr,
! #if defined(__solaris__) && defined(__sparc__)
/* use intimate shared memory on Solaris */
SHM_SHARE_MMU
#else
---(end of broadcast)---
TIP 8: explain analyze is your friend
[BUGS] PostgreSQL Patch: Test-and-set routine for HP-UX (IA-64)
Subject: PostgreSQL Patch: Test-and-set routine for HP-UX (IA-64) Hello, The attached patch provides a test-and-set routine for PostgreSQL for HP-UX 11iV2 for the Intel Itanium architecture (known to the PostgreSQL code as IA-64). There are actually two issues: 1. There is currently no tas (test-and-set) routine for HP-UX IA-64 in the s_lock.h header file. 2. In HP-UX IA-64, the suffix of shared libraries is ".so", but PostgreSQL generates a ".sl" suffix. The attached patch fixes both issues. The bug template (also attached) contains the details. We (ViSolve) are a group that works closely with HP on their OpenSource initiative. We would really appreciate a timely inclusion of this patch into mainstream PostgreSQL. thanks ViSolve OpenSource Team (for HP) PostgreSQL_bug.template Description: Binary data PostgreSQL-7.3.4_hpux3_11iv2_IA-64.patch.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] PostgreSQL Patch: Test-and-set routine for HP-UX
I am unable to get this patch to compile: gcc version : gcc (GCC) 3.2 20020329 (experimental) uname -srm : HP-UX B.11.22 ia64 tar xvf postgresql-7.3.4.tar cd postgresql-7.3.4 patch -p0 ../PostgreSQL-7.3.4_hpux3_11iv2_IA-64.patch ./configure [snip] make [snip] gmake[4]: Entering directory `/home/postgres/src/postgresql-7.3.4/src/backend/ac cess/transam' gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/incl ude -c -o xlog.o xlog.c xlog.c: In function `XLogInsert': xlog.c:641: incompatible types in assignment xlog.c:870: incompatible types in assignment xlog.c: In function `AdvanceXLInsertBuffer': xlog.c:929: incompatible types in assignment xlog.c: In function `XLogWrite': xlog.c:1189: incompatible types in assignment xlog.c: In function `XLogFlush': xlog.c:1248: incompatible types in assignment xlog.c: In function `XLOGShmemInit': xlog.c:2361: incompatible types in assignment xlog.c: In function `GetRedoRecPtr': xlog.c:2918: incompatible types in assignment xlog.c: In function `CreateCheckPoint': xlog.c:3068: incompatible types in assignment gmake[4]: *** [xlog.o] Error 1 gmake[4]: Leaving directory `/home/postgres/src/postgresql-7.3.4/src/backend/acc ess/transam' gmake[3]: *** [transam-recursive] Error 2 This seems to be a problem with SpinLockRelease_NoHoldoff. On Fri, 2003-10-24 at 11:51, ViSolve Open Source Team wrote: > Subject: PostgreSQL Patch: Test-and-set routine for HP-UX (IA-64) > > > Hello, > > The attached patch provides a test-and-set routine for PostgreSQL for HP-UX > 11iV2 for the Intel Itanium architecture (known to the PostgreSQL code as > IA-64). There are actually two issues: > > 1. There is currently no tas (test-and-set) routine for HP-UX IA-64 in the > s_lock.h header file. > 2. In HP-UX IA-64, the suffix of shared libraries is ".so", but PostgreSQL > generates a ".sl" suffix. > > The attached patch fixes both issues. The bug template (also attached) > contains the details. > > We (ViSolve) are a group that works closely with HP on their OpenSource > initiative. We would really appreciate a timely inclusion of this patch > into mainstream PostgreSQL. > > thanks > ViSolve OpenSource Team (for HP) > > __ > ---(end of broadcast)--- > TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
