[BUGS] Bug?
POSTGRESQL BUG REPORT TEMPLATE Your name : Sean Kelly Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Pentium (133MHz) Operating System (example: Linux 2.0.26 ELF) : Linux 2.0.38 ELF PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.2 Compiler used (example: gcc 2.8.0) : gcc version 2.7.2.3 Please enter a FULL description of your problem: I am attempting to do a new installation of PostgreSQL 7.0.2 (although this problem also occured with 7.0.0). I follow the doc INSTALL exactly, but I have a problem when trying to start the postmaster backend. I get the following error on executing "/home/postgres/bin/postmaster -D /home/postgres/data": ---[ Cut ]--- IpcMemoryCreate: shmget failed (Invalid argument) key=5432010, size=144, permission=700 This type of error is usually caused by an improper shared memory or System V IPC semaphore configuration. For more information, see the FAQ and platform-specific FAQ's in the source directory pgsql/doc or on our web site at http://www.postgresql.org. IpcMemoryIdGet: shmget failed (Invalid argument) key=5432010, size=144, permission=0 IpcMemoryAttach: shmat failed (Invalid argument) id=-2 FATAL 1: AttachSLockMemory: could not attach segment ---[ Cut ]--- My kernel has been compiled with "System V IPC" selected. PostgreSQL 6.5.3 has been compiled and ran on this system. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- By following the doc INSTALL through again, the same problem occurs on trying to start the postmaster backend. If you know how this problem might be fixed, list the solution below: - [None]
[BUGS] "IpcMemoryCreate: shmget failed" on 2.0.38 (was Re: Bug?)
On Wed, 7 Jun 2000, Tom Lane wrote: > > IpcMemoryCreate: shmget failed (Invalid argument) key=5432010, size=144, >permission=700 > > My kernel has been compiled with "System V IPC" selected. > > PostgreSQL 6.5.3 has been compiled and ran on this system. > > Hmm, maybe there are old shmem segments still present from the 6.5.3 > postmaster? You might need to 'ipcrm' the old ones. See our ipcclean > script for help. > Thanks for the advice Tom. The following happened: -> ./ipcclean ipcclean: nothing removed -> postmaster -D /home/postgres/data/ IpcMemoryCreate: shmget failed (Invalid argument) key=5432010, size=144, permission=700 This type of error is usually caused by an improper shared memory or System V IPC semaphore configuration. [SNIP: Same as previous message] Anything else that could solve this? == Sean.
[BUGS] More "IpcMemoryCreate: shmget failed" errors
Hello again, A couple of weeks ago I reported a problem installing both 7.0 and 7.0.2 where attempting to start "postmaster" produced an "IpcMemoryCreate: shmget failed"-type error. Tom Lane suggested I use the "ipcclean" application to remove the "old shmem segments". Running "ipcclean" with 7.0.2 gave "ipcclean: nothing removed" as the result "but postmaster" still gave the same "IpcMemoryCreate: shmget failed" error. So ... I deleted this 7.0.2 installation and decided to go back to 6.5.3. This installed, but when trying to start "postmaster" I got: - - - - IpcMemoryCreate: shmget failed (Permission denied) key=5432010, size=120, permission=700 IpcMemoryAttach: shmat failed (Permission denied) id=130 FATAL 1: AttachSLockMemory: could not attach segment - - - - So, I ran ipcclean that comes with 6.5.3 which finished with no messages, but "postmaster" still gives the "IpcMemoryCreate: shmget failed". Hence, I cannot run PostgreSQL on this system any more :( Any suggestions? Is there a way that v7 could check for these old segments from v6 and remove them? Is this even the problem here? Any other ways to clear these suspected old segments at all? Thanks for your time, -- Sean Kelly <[EMAIL PROTECTED]> "The best way to predict the future is to invent it" - Alan Kay
Re: [BUGS] More "IpcMemoryCreate: shmget failed" errors
On Fri, 16 Jun 2000, The Hermit Hacker <[EMAIL PROTECTED]> wrote: > > Okay, my first question is is *what* OS are you running on? I get this > sort of error under Solaris if I use a defautl install of both the OS and > PostgreSQL, and have to use the -B option to reduce the number of segments > that PostgreSQL wants to configure ... Sorry for not including the OS to all those who replied to me ... I guess I thought people would refer back to my original post which was submitted using the standard template :/ Apologies... I am running Linux 2.0.38 on an Intel Pentium 133Mhz. > v6.5.3, I believe it was, changed the IPC usage so that it allocates all > it needs when you start, vs growing as required, so that it pre-allocates > ... so if you were using a pre-"this code" version and moving up, this > might be triggering your problem ... The machine used to run 6.5.3. I then attempted an upgrade to 7.0.0 and started to get these "IpcMemoryCreate: shmget failed" errors. I then tried 7.0.2 and the errors continued. I then tried to revert back to 6.5.3 and got more "IpcMemoryCreate: shmget failed" errors. On Fri, 16 Jun 2000, Tom Lane <[EMAIL PROTECTED]> wrote: > Have you done any actual investigation --- like looked at the output > of ipcs -m -a to see whether there are old segments lying around? I've never really messed with ipcs (and any of its family) before ... I'm just trying to upgrade the installation and am meeting problems. I am investigating the use of ipcs (and its family) on a devel machine before I move onto 'playing' with shared memory on the production box. > The ipcclean script is not very bright, and in particular I doubt it > knows about all the formats that different platforms' versions of > ipcs produce. So it may just be failing to recognize what has to be > removed. > > The "Permission denied" error suggests that you may be trying to run > Postgres under a different userid than you were before. If so, you'll > have to delete the old segments as that other user, or as root. PostgreSQL 6.5.3 ran under user postgres beforehand, and 7.0.0/7.0.2 is also being ran under user postgres. On Fri, 16 Jun 2000, Ronald Kuczek <[EMAIL PROTECTED]> wrote: > Hi ! > And your OS ? > Sorry, I did't followed your story. If you tell me, I can help you. [Covered above] Thanks to all who replied, your help is greatly appreciated. -- Sean Kelly <[EMAIL PROTECTED]> "The best way to predict the future is to invent it" - Alan Kay
[BUGS] ";" no longer allowed to terminate a command beginning with "\"
Hi there, Just would like some "is this a bug or a feature"-style clarification on this please. In PostgreSQL v6.5 you used to be able to end a command issued to "psql" starting with a backslash "\" with a semicolon ";", eg. bookmarks=> \d sites_tbl; Table= sites_tbl ... TABLE HERE ... However, in PostgreSQL v7.0.2, this does not happen, eg. projman_dev=# \d login_tbl; Did not find any relation named "login_tbl;". [even though there _is_ a table called login_tbl] I know that SQL statements end with a semi-colon, and I also know that the backslashed commands are _not_ SQL statements. In my case, I know I am used to ending almost everything I write with a semicolon but was just wondering whether this was a planned change to the "psql" application. Thanks for your time, -- Sean Kelly <[EMAIL PROTECTED]> "The best way to predict the future is to invent it" - Alan Kay
Re: [BUGS] How to connect to a remote database
On Thu, 7 Sep 2000 07:21:57 -0400 (EDT), [EMAIL PROTECTED] said: > Martin Kuria ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description > How to connect to a remote database > > Long Description > This may be a dumb question, but how do I connect to a remote database > using postgresql, or rather psql? This isn't really a bug, is it? :) "man psql" shows your options - you need "-h hostname_here". See "man psql" for more. You'll probably have to edit /path/to/pgsql/lib/pg_hba.conf on the remote machine to get permission. Thanks, -- Sean Kelly <[EMAIL PROTECTED]> "The best way to predict the future is to invent it" - Alan Kay
Re: [BUGS] Updating multiple bool values crashes backend
Here is a debug (level 2) output - does this help any more?... If not, what should I provide for you in terms of debugging?... FindExec: found "/usr/local/postgres/bin/postgres" using argv[0] binding ShmemCreate(key=52e2c1, size=1104896) DEBUG: Data Base System is starting up at Wed Oct 25 13:15:17 2000 DEBUG: Data Base System was shut down at Wed Oct 25 13:14:49 2000 DEBUG: Data Base System is in production state at Wed Oct 25 13:15:17 2000 proc_exit(0) shmem_exit(0) exit(0) /usr/local/postgres/bin/postmaster: reaping dead processes... /usr/local/postgres/bin/postmaster: ServerLoop: handling reading 5 /usr/local/postgres/bin/postmaster: ServerLoop: handling reading 5 /usr/local/postgres/bin/postmaster: ServerLoop: handling writing 5 /usr/local/postgres/bin/postmaster: BackendStartup: pid 28428 user sean db users socket 5 /usr/local/postgres/bin/postmaster child[28428]: starting with (/usr/local/postgres/bin/postgres -d2 -v131072 -p users ) FindExec: found "/usr/local/postgres/bin/postgres" using argv[0] started: host=localhost user=sean database=users InitPostgres StartTransactionCommand query: SELECT usesuper FROM pg_user WHERE usename = 'sean' ProcessQuery CommitTransactionCommand StartTransactionCommand query: delete from dialup_tbl where username='sib'; ProcessQuery CommitTransactionCommand StartTransactionCommand query: delete from users_tbl where username='sib'; ProcessQuery query: SELECT oid FROM "dialup_tbl" WHERE "username" = $1 FOR UPDATE OF "dialup_tbl" /usr/local/postgres/bin/postmaster: reaping dead processes... /usr/local/postgres/bin/postmaster: CleanupProc: pid 28428 exited with status 11 Server process (pid 28428) exited with status 11 at Wed Oct 25 13:15:35 2000 Terminating any active server processes... Server processes were terminated at Wed Oct 25 13:15:35 2000 Reinitializing shared memory and semaphores shmem_exit(0) binding ShmemCreate(key=52e325, size=1104896) /usr/local/postgres/bin/postmaster: ServerLoop: handling reading 5 /usr/local/postgres/bin/postmaster: ServerLoop: handling reading 5 DEBUG: Data Base System is starting up at Wed Oct 25 13:15:35 2000 DEBUG: Data Base System was interrupted being in production at Wed Oct 25 13:15:17 2000 /usr/local/postgres/bin/postmaster: ServerLoop: handling writing 5 The Data Base System is starting up /usr/local/postgres/bin/postmaster: ServerLoop: handling writing 5 DEBUG: Data Base System is in production state at Wed Oct 25 13:15:35 2000 proc_exit(0) shmem_exit(0) exit(0) /usr/local/postgres/bin/postmaster: reaping dead processes... Thanks, -- Sean Kelly <[EMAIL PROTECTED]> "If 99% is good enough, then gravity will not work for 14 minutes every day."
Re: [BUGS] Updating multiple bool values crashes backend
On Wed, 25 Oct 2000 14:14:22 -0400, Tom Lane said: > >No core there ... any other suggestions? > > You probably started the postmaster with a ulimit setting that prevents > coredumps (ulimit -c 0 or something like that, see your ulimit man page). > On some Unixen, this ulimit setting is the default for anything started > from a system boot script. Restart the postmaster with ulimit -c > unlimited, either by starting it by hand or adding a ulimit call to the > boot script. Then reproduce the crash to get a core file. Ok, I sorted that ... I now have a 2Mb core file. Can you explain how to 'backtrace' it with gdb ... I'm not really a developer and haven't played with gdb much ... ever ... I've stuck the core file at http://www.randomfx.net/core.html if you need it. As someone suggested, I 'pg_dump'ed the database, 'dropdb'ed and 'createdb'ed it, before reloading. After reloading the results were the same. I tried this on both the machines running 7.0.2 with the same results. > > With respect to GCC errors, '11' normally indicates a hardware > > problem > > Uh, whoever told you that? Signal 11 is SIGSEGV on most Unixen, > and that just means the program tried to dereference an invalid > pointer. Almost certainly, we're looking at some software bug > here, not a hardware failure. One example can be found on http://www.bitwizard.nl/sig11/ Thanks for your time and help, -- Sean Kelly <[EMAIL PROTECTED]> "If 99% is good enough, then gravity will not work for 14 minutes every day."
Re: [BUGS] Updating multiple bool values crashes backend
On Fri, 27 Oct 2000 11:55:24 -0700, Darcy Buskermolen said:
> Could it also be the result of a Cluster operation? I've seen strange
> things related to functions/triggers on tables that I've clustered.
Personally for me it turned out to be, as Tom said, the
renaming of a table involving foreign keys. I renamed the table back
to what it was, dropped it, and then recreated the new one with new
foreign keys.
Thanks,
--
Sean Kelly <[EMAIL PROTECTED]>
"If 99% is good enough, then gravity will not work for 14 minutes
every day."
Re: [BUGS] backend closed the channel unexpectedly?!?
On Wed, 08 Nov 2000 16:54:40 +0200, Martti Hertzen said: > testsqc=> DELETE FROM henkilo WHERE id = 12; > 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. > !> > > Here's the output of the debug channel: > > 001108.16:31:16.753 [31195] StartTransactionCommand > 001108.16:31:16.753 [31195] query: DELETE FROM henkilo WHERE id = 12; > 001108.16:31:16.840 [31195] ProcessQuery > postmaster: reaping dead processes... > postmaster: CleanupProc: pid 31195 exited with status 139 > Server process (pid 31195) exited with status 139 at Wed Nov 8 16:31:17 > 2000 > Terminating any active server processes... > Server processes were terminated at Wed Nov 8 16:31:17 2000 > Reinitializing shared memory and semaphores > 001108.16:31:17.822 [30871] shmem_exit(0) > binding ShmemCreate(key=52e4b5, size=1104896) I had this problem after renaming OLD_TABLE to NEW_TABLE after creating foreign keys in OLD_TABLE referencing MASTER_TABLE. Listen to Tom ... he knows his stuff ;) -- Sean Kelly <[EMAIL PROTECTED]> "If 99% is good enough, then gravity will not work for 14 minutes every day."
Re: [BUGS] Updating multiple bool values crashes backend
On Wed, 25 Oct 2000 12:52:44 -0400, Tom Lane said: > [EMAIL PROTECTED] writes: > > users=> update users_tbl set added=TRUE where username like 'neta%'; > > pqReadData() -- backend closed the channel unexpectedly. > > > bash$ tail ~postgres/server.log > > Server process (pid 23747) exited with status 11 at Tue Oct 24 13:52:29 2000 > > This backend crash should have left a core file in your database > directory (PGDATA/base/users/core). Can you provide a backtrace > from that corefile using gdb? No core there ... any other suggestions? With respect to GCC errors, '11' normally indicates a hardware problem - could this be the case? One of the machines I tested it on was brand new hardware... Thanks, -- Sean Kelly <[EMAIL PROTECTED]> "If 99% is good enough, then gravity will not work for 14 minutes every day."
Re: [BUGS] Updating multiple bool values crashes backend
On Thu, 26 Oct 2000 10:14:16 -0400, Tom Lane said: > gdb /path/to/postgres-executable /path/to/core-file > bt > quit [postgres@nis-master] ~ 132: gdb bin/postgres data/base/users/core This GDB was configured as "i386-slackware-linux"... Core was generated by `/usr/local/postgres/bin/postgres localhost s'. Program terminated with signal 11, Segmentation fault. .. [SNIP: Loading symbols...] .. #0 0x8115eb2 in ri_BuildQueryKeyFull () (gdb) bt #0 0x8115eb2 in ri_BuildQueryKeyFull () #1 0x8115dc2 in RI_FKey_keyequal_upd () #2 0x8096d7c in DeferredTriggerSaveEvent () #3 0x8096016 in ExecARUpdateTriggers () #4 0x809c617 in ExecReplace () #5 0x809c256 in ExecutePlan () #6 0x809b8f3 in ExecutorRun () #7 0x80eb46a in ProcessQueryDesc () #8 0x80eb4d0 in ProcessQuery () #9 0x80ea153 in pg_exec_query_dest () #10 0x80ea033 in pg_exec_query () #11 0x80eaeec in PostgresMain () #12 0x80d565a in DoBackend () #13 0x80d523a in BackendStartup () #14 0x80d45ee in ServerLoop () #15 0x80d407c in PostmasterMain () #16 0x80ab115 in main () #17 0x400f9577 in __libc_start_main () from /lib/libc.so.6 (gdb) quit There we go :) Thanks, -- Sean Kelly <[EMAIL PROTECTED]> "If 99% is good enough, then gravity will not work for 14 minutes every day."
Re: [BUGS] Updating multiple bool values crashes backend
On Thu, 26 Oct 2000 11:27:22 -0400, Tom Lane said: > Sean Kelly <[EMAIL PROTECTED]> writes: > > (gdb) bt > > #0 0x8115eb2 in ri_BuildQueryKeyFull () > > #1 0x8115dc2 in RI_FKey_keyequal_upd () > > #2 0x8096d7c in DeferredTriggerSaveEvent () > > Hmm. There wasn't any mention of foreign keys for this table in your > bug report, now was there? > > At a guess, you've run into the known bug that foreign key triggers > don't track renames of referenced tables. Did you rename a table that > is a foreign-key referencer or referencee of this one? If so, rename > it back, or drop and reload both tables. (The crash is fixed for > 7.0.3, though actually tracking the renames is further downstream.) Ah ha! oldname_tbl referenced the primary key in users_tbl, and oldname_tbl was renamed newname_tbl. Is this the bug you mean?... When you say drop/reload both tables do you mean both users_tbl and newname_tbl?... Thanks, I think it's nearly sorted now :) -- Sean Kelly <[EMAIL PROTECTED]> "If 99% is good enough, then gravity will not work for 14 minutes every day."
[BUGS] "select ... where field like lower('%text%')" fails
Hello,
I was trying to send the following bug report from the web page
but it kept timing out. I hope this is the only time it arrives on the
list...
I am trying to search a varchar(x) field with a query like:
select ... where field like lower('%someText%')
In one field, if the value someText is at the very start then the
search fails. In another field, if the value someText is at the very
start then the search succeeds.
Here are some statements (the ones returning 0 rows should be
returning something):
isp=> \d user_tbl
Table "user_tbl"
Attribute |Type |Modifier
---+-+-
username | varchar(10) | not null
company | varchar(80) | not null
email | varchar(80) |
password | varchar(20) | not null
active| boolean | not null default 'TRUE'
created | timestamp | not null
Index: user_tbl_pkey
isp=> SELECT username,company,active,created
isp-> from user_tbl where username;
username | company | active |created
--+-++
sean | Sean's Test Company | t | 2001-01-14 14:01:58+00
(1 row)
isp=> SELECT username,company,active,created
isp-> from user_tbl where username like lower('%SEaN%');
username | company | active |created
--+-++
sean | Sean's Test Company | t | 2001-01-14 14:01:58+00
(1 row)
isp=> SELECT username,company,active,created
isp-> from user_tbl where company like lower('%SEaN%');
username | company | active | created
--+-++-
(0 rows)
isp=> SELECT username,company,active,created
isp-> from user_tbl where company like lower('SEaN%');
username | company | active | created
--+-++-
(0 rows)
isp=> SELECT username,company,active,created
isp-> from user_tbl where company like lower('%EaN%');
username | company | active |created
--+-++
sean | Sean's Test Company | t | 2001-01-14 14:01:58+00
(1 row)
Any advice?
Thanks,
--
Sean
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] An statement causes postmaster to die
On Sun, 22 Apr 2001, [EMAIL PROTECTED] wrote: > Can't tell much of anything from this. Can you provide a gdb backtrace > from the corefile that the failed backend presumably left? It should be > in $PGDATA/base/isp/core. I have the core file but cannot remember how to make a backtrace. Can you give me the steps please? Thanks, -- Sean ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] An statement causes postmaster to die
On Sun, 22 Apr 2001, [EMAIL PROTECTED] wrote: > Can't tell much of anything from this. Can you provide a gdb backtrace > from the corefile that the failed backend presumably left? It should be > in $PGDATA/base/isp/core. Please ignore my last mail, I've found some documentation. Starting gdb like: gdb ~/bin/postgres core as the PostgreSQL user and getting a backtrace looks like: (gdb) bt #0 0x8115eb2 in ri_BuildQueryKeyFull () #1 0x8115dc2 in RI_FKey_keyequal_upd () #2 0x8096d7c in DeferredTriggerSaveEvent () #3 0x8096016 in ExecARUpdateTriggers () #4 0x809c617 in ExecReplace () #5 0x809c256 in ExecutePlan () #6 0x809b8f3 in ExecutorRun () #7 0x80eb46a in ProcessQueryDesc () #8 0x80eb4d0 in ProcessQuery () #9 0x80ea153 in pg_exec_query_dest () #10 0x80ea033 in pg_exec_query () #11 0x80eaeec in PostgresMain () #12 0x80d565a in DoBackend () #13 0x80d523a in BackendStartup () #14 0x80d45ee in ServerLoop () #15 0x80d407c in PostmasterMain () #16 0x80ab115 in main () #17 0x400fa577 in __libc_start_main () from /lib/libc.so.6 (gdb) Thanks, -- Sean ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
