[BUGS] IpcSemaphoreCreate: semget(...) failed: No space left on device
I shortened the error msg to fit it into the subject box. I just completed a fresh install (not upgrade) of MDK 9.2 onto a 1.0 GHz Athlon with 512 MB of RAM. The PostgreSQL 7.3.4 RPMs were installed when I did the MDK 9.2 install, which also created the postgres account. The 'short version' for installation worked perfectly up to the following step: initdb -D /usr/local/pgsql/data which I have used for several years, failed on me for the first time, giving the error msg shown in the Subject box. I am not going to recompile MDK's kernel to raise the maximum number of semaphores (SEMMNS), and the 'max_connections' parameter is currently at 1 and can't go lower, unless it is indexed starting at zero. I was unable to post this to the Mandrake Bugzilla page because it is down. What is the possiblity that I would encounter this error if I were to remove the 7.3.4 RPMs and install the 7.4 tar files manually? TIA! -- GreyGeek ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] IpcSemaphoreCreate: semget(...) failed: No space left on device
jerry wrote: jerry wrote: I shortened the error msg to fit it into the subject box. I just completed a fresh install (not upgrade) of MDK 9.2 onto a 1.0 GHz Athlon with 512 MB of RAM. The PostgreSQL 7.3.4 RPMs were installed when I did the MDK 9.2 install, which also created the postgres account. The 'short version' for installation worked perfectly up to the following step: initdb -D /usr/local/pgsql/data which I have used for several years, failed on me for the first time, giving the error msg shown in the Subject box. I am not going to recompile MDK's kernel to raise the maximum number of semaphores (SEMMNS), and the 'max_connections' parameter is currently at 1 and can't go lower, unless it is indexed starting at zero. I was unable to post this to the Mandrake Bugzilla page because it is down. What is the possiblity that I would encounter this error if I were to remove the 7.3.4 RPMs and install the 7.4 tar files manually? TIA! -- GreyGeek I'll answer my own question: NO! gmake[3]: Leaving directory `/home/jerry/postgresql-7.4/contrib/spi' /bin/sh ./pg_regress --temp-install --top-builddir=../../.. --schedule=./parallel_schedule --multibyte=SQL_ASCII == creating temporary installation== == initializing database system == pg_regress: initdb failed Examine ./log/initdb.log for the reason. The initdb.log gave the exact same reason for failure, except for: reduce PostgreSQL's consumption of semaphores by reducing its max_connections parameter (currently 10). I know from the error msg in the RPM installation that even with a 'max_connections = 1 the failure occurres. It seems that the standard MDK 9.2 kernel (2.4.22-10mdk) is not compatible with PostgreSQL 7.3.4 or 7.4. ??? sheesh! Some days I should stay in bed. Ignore this thread. The problem is operator error. -- GreyGeek -- -- GreyGeek ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] RC1 question of reloading data
Theodore Petrosky wrote: So, I was logged on as postgres. but there is no database called 'postgres' (or maybe I don't understand the internals). Keep in mind that I am only looking for understanding of the process... and I want to make sure that doing this doesn't create problems later. Ted Postgres is not a 'database', it is the account name which owns the commands and the directories with which and into which the database structure is created using initdb. If you followed the short installation version you would have done something like this: jerry$ su [EMAIL PROTECTED] mkdir /usr/local/pgsql/data [EMAIL PROTECTED] chown postgres /usr/local/pgsql/data [EMAIL PROTECTED] su - postgres -bash-2.05b$ initdb -D /usr/local/pgsql/data Then you could log in using psql and create your user name and db template, etc. -- GreyGeek ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] memory bug
Hello, i have a problem related to the partition memory where postgres is installed, this has increased so much that the partition is full and postgres can not start up. Themessage postmaster sends when i want to restart is insuficient disk space. Do you know if postgres uses some disk space that may not releases. Thanks in advance for your help... Alexander AlbarracinCORE SECURITY TECHNOLOGIESFlorida 141 - 2º cuerpo - 7º pisoC1005AAC Buenos Aires - ArgentinaTel/Fax: (54 11) 5032-CORE (2673)http://www.corest.com
[BUGS] 7.4: FATAL: unrecognized configuration parameter show_statement_stats
Version: Release 7.4 (production) Error message: psql: FATAL: unrecognized configuration parameter show_statement_stats This is reproducible if start the engine with option -o -s. (defined in src/backend/tcop/postgres.c) My command to start engine is: nohup /app/pgsql/7.4/bin/postmaster -B 1024 -D /app/pgsql/data pg74.log 21 ---(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
[BUGS] inner query bug
I was advised to send an e-mail after a discussion with neilc on
#postgresql.
The failure occurs randomly, never on the first time (at least that I've
seen) and usually only after doing a bunch of other stuff first (big
joins, views, etc). In one case, the backend terminated and restarted,
this has only happened once.
P4 w/1024 GB ram. RH9
uname -a
Linux gecko.paycheckadv.com 2.6.0-0.test9.1.90 #1 Tue Nov 18 09:34:47
EST 2003 i686 i686 i386 GNU/Linux
psql output follows:
SC2test7=# select * from txstatus,tx txx where txstatus.txid = txx.txid
AND txstatus.statuschangetime = (select max(txstatus.statuschangetime)
from txstatus where txstatus.txid = txx.txid); FATAL: terminating
connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
SC2test7=# \d txstatus
no connection to the server
The connection to the server was lost. Attempting reset: Succeeded.
SC2test7=# \d txstatus
Table public.txstatus
Column | Type
|Modifiers
--+--+--
txstatusid | integer | not null default
nextval('public.txstatus_txstatusid_seq'::text)
statusid | integer | not null
txid | integer | not null
statuschangetime | timestamp with time zone | not null
employeeid | integer | not null
Indexes: pk_txstatus_txstatusid primary key btree (txstatusid),
idx_txstatus_statuschangetime btree (statuschangetime)
Foreign Key constraints: fk_txstatus_statusid FOREIGN KEY (statusid)
REFERENCES status(statusid),
fk_txstatus_txid FOREIGN KEY (txid) REFERENCES
tx(txid),
fk_txstatus_employeeid FOREIGN KEY (employeeid)
REFERENCES employee(employeeid)
SC2test7=# \d tx
Table public.tx
Column | Type |
Modifiers
---+--+--
txid | integer | not null default
nextval('public.tx_txid_seq'::text)
txtypeid | integer | not null
statusid | integer | not null
amount| numeric(6,2) | not null
servicecharge | numeric(6,2) | not null
customeraccountid | integer |
checksid | integer |
rent | numeric(6,2) |
scheduledpayments | integer |
txtimestamp | timestamp with time zone | not null
Indexes: pk_tx_txid primary key btree (txid),
idx_tx_statusid btree (statusid),
idx_tx_txtypeid btree (txtypeid)
Foreign Key constraints: fk_tx_txtypeid FOREIGN KEY (txtypeid)
REFERENCES txtype(txtypeid),
fk_tx_statusid FOREIGN KEY (statusid)
REFERENCES status(statusid),
fk_tx_customeraccountid FOREIGN KEY
(customeraccountid) REFERENCES customeraccount(customeraccountid),
fk_tx_checksid FOREIGN KEY (checksid)
REFERENCES checks(checksid)
select * from txstatus,tx txx where txstatus.txid = txx.txid AND
txstatus.statuschangetime = (select max(txstatus.statuschangetime) from
txstatus where txstatus.txid = txx.txid);
ERROR: variable not found in subplan target list
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[BUGS] Bug Report
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the problem but solved it and generated a patch
then e-mail it to [EMAIL PROTECTED] instead. Please use the
command diff -c to generate the patch.
You may also enter a bug report at http://www.postgresql.org/ instead of
e-mail-ing this form.
POSTGRESQL BUG REPORT TEMPLATE
Your name : Douglas M. Westfall
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel P4 Itanium 2.4
Operating System (example: Linux 2.0.26 ELF) : Linux
2.4.22-1.2087.nptlsmp #1 SMP i686 i686 i386 GNU/Linux (RH9+)
PostgreSQL version (example: PostgreSQL-7.3.4): PostgreSQL-7.3.4
Compiler used (example: gcc 2.95.2) : RH9 using Ximian RUG rpm's ...
update of 19 Nov 2003
Please enter a FULL description of your problem:
1) table contains a valid inet field
2) query works fine in pgsql 7.2 7.3
3) query no longer works in pgsql 7.4
select * from table where field ilike '%inetvalue%' ;
fails with:
ERROR: Unable to identify an operator '~~*' for types 'inet' and
'unknown'
You will have to retype this query using an explicit cast
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
select * from ipaddrs2 where ip2_address ilike '%10.123.252.4%' order by
ip2_address asc;
CASTing the operator provides no resolution, as it causes syntax errors,
ie:
select * from ipaddrs2 where ip2_address ilike '%10.123.252.4%'::inet
order by ip2_address asc;
returns:
ERROR: invalid INET value '%10.123.252.4%'
AND:
select * from ipaddrs2 where ip2_address ilike CAST('%10.123.252.4% as
inet) order by ip2_address asc;
returns:
ERROR: invalid INET value '%10.123.252.4%'
If you know how this problem might be fixed, list the solution below:
-
Apparent problem in ilike function dealing with inet values
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[BUGS] (Modified) Patch request for PostgreSQL 7.4 for HP-UX IA-64
Subject: PostgreSQL Patch: Modified Test-and-set routine for HP-UX (IA-64) specifically for the HP-C compiler With reference to Tom Lane's response to our previous patch request (at http://archives.postgresql.org/pgsql-bugs/2003-10/msg00149.php)this is a modified andmore focussedpatch request for PostgreSQL for for HP-UX11i V2 for the Intel Itanium architecture (known to the PostgreSQL code asIA-64). The patch is required for HP-UX customers who want to compile the productwith the HP-C compiler. We have a significant number of HP-UX users who wantto build PostgreSQL on the IA-64 platform, but with the HP-C compiler. The primarycontent of this patch isinline tas code that will build with HP-C. There is one side-effect (described later) of using HP-C, also addressed by the patch. The target versionis PostgreSQL 7.4. We have downloaded the source (on Nov 18),applied the patch, and have testedit successfully. Note: HP-UX users building the product with the gcc compiler can use the 7.4 version (or even the 7.3.4 version). Details for the patch are in the attached template file. A summary is providedhere: Version: PostgreSQL 7.4 Files modified: 1. s_lock.h: modified with inline tas code for the HP-C compiler 2. genbki.sh: a one-line change that fixes a string concatenation problem with the HP-C compiler (specific to included .c files). thanksViSolve OpenSource Team (for HP) PostgreSQL_74_taspatch_hpux_ia64_hpc.patch Description: Binary data POSTGRESQL BUG REPORT TEMPLATE Your name : ViSolve OpenSource team (for HP) Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Itanium Operating System (example: Linux 2.0.26 ELF) : HP-UX 11.2x PostgreSQL version (example: PostgreSQL-7.3.4): PostgreSQL-7.4 Compiler used (example: gcc 2.95.2) : HP-C for HP-UX IA-64 Please enter a FULL description of your problem: This patch will allow HP-UX users to build the PostgreSQL 7.4 code correctly using the HP-C compiler, with the appropriate (inline) tas code that will work for HP-UX IA-64. We have a significant number of HP customers who want to build PostgreSQL on this platform, but with HP-C instead of gcc. The IA-64 inline tas code that comes with the 7.4 version is gcc-specific, and hence the need for this patch. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- There are 2 problems here: 1. The current gcc-specific inline tas code (for IA-64) in s_lock.h will not compile with HP-c 2. There is an additional issue (unrelated to tas) related to HP-C generating incorrect code in postgres.bki. If you know how this problem might be fixed, list the solution below: - The attached patch fixes the problems described above. The patch modifies two files: 1. s_lock.h: modified to include inline tas code that can be compiled by the HP-C compiler. 2. genbki.sh: modified to correctly generate postgres.bki using HP-C. Without this modification, the HP-C environment generates bad code in postgres.bki that causes several functions to fail. One example of bad code is shown below: With gcc: insert OID = 1296 ( timedate_pl 11 1 14 f f t f i 2 1114 1083 1082 select ($2 + $1) - _null_ ) with HP-C: insert OID = 1296 ( timedate_pl 11 1 14 f f t f i 2 1114 1083 1082select ($2 + $1) - _null_ ) The HP-C compiler concatenates adjacent double-quoted strings into a single string. It does this only for .c files. That is the problem. Our fix consists of a one-line change. The line: TMPFILE = $TMPDIR/genbkitmp.c is modified to: TMPFILE = $TMPDIR/genbkitmp.h The gcc compiler does not care whether an included file is .c or .h, so other platforms will not be impacted. FYI, some relevant discussion can also be found at http://archives.postgresql.org/pgsql-general/2003-01/msg00924.php If you don't find this one-line change appropriate, we will need to manually change it each time we get a new PostgreSQL version - not ideal, but not too bad either. The s_lock.h modification has been coded to be used only by the HP-C compiler. Note: We also noticed that the 7.4(STABLE) version has already modified the configure.in file to explicitly provide a tas_file name for hppa*-*-hpux* thereby excluding IA-64 from the list. This is different from the 7.3.4 version where the tas_file name was provided
Re: [BUGS] Bug Report
Yes, I have searched the archives, and searches for 'inet' or 'ilike' or
'inet+ilike' and 'inetilike' return 0 results each.
Have I missed something?
Regards,
DougW
On Thu, 2003-11-20 at 23:09, Douglas M. Westfall wrote:
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the problem but solved it and generated a patch
then e-mail it to [EMAIL PROTECTED] instead. Please use the
command diff -c to generate the patch.
You may also enter a bug report at http://www.postgresql.org/ instead of
e-mail-ing this form.
POSTGRESQL BUG REPORT TEMPLATE
Your name : Douglas M. Westfall
Your email address: [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel P4 Itanium 2.4
Operating System (example: Linux 2.0.26 ELF): Linux
2.4.22-1.2087.nptlsmp #1 SMP i686 i686 i386 GNU/Linux (RH9+)
PostgreSQL version (example: PostgreSQL-7.3.4): PostgreSQL-7.3.4
Compiler used (example: gcc 2.95.2): RH9 using Ximian RUG
rpm's ...
update of 19 Nov 2003
Please enter a FULL description of your problem:
1) table contains a valid inet field
2) query works fine in pgsql 7.2 7.3
3) query no longer works in pgsql 7.4
select * from table where field ilike '%inetvalue%' ;
fails with:
ERROR: Unable to identify an operator '~~*' for types 'inet' and
'unknown'
You will have to retype this query using an explicit cast
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
select * from ipaddrs2 where ip2_address ilike '%10.123.252.4%' order by
ip2_address asc;
CASTing the operator provides no resolution, as it causes syntax errors,
ie:
select * from ipaddrs2 where ip2_address ilike '%10.123.252.4%'::inet
order by ip2_address asc;
returns:
ERROR: invalid INET value '%10.123.252.4%'
AND:
select * from ipaddrs2 where ip2_address ilike CAST('%10.123.252.4% as
inet) order by ip2_address asc;
returns:
ERROR: invalid INET value '%10.123.252.4%'
If you know how this problem might be fixed, list the solution below:
-
Apparent problem in ilike function dealing with inet values
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
