[BUGS] making 7.4 beta2 on Mac OS x
I thought I would try to make 7.4beta2 on my os X machine. I used the default ./configure then make. make says everything is ok to install so I tried a make check.. this is my error log. gcc is set for 3.1 os X 10.2.6. I don't know if this is just a 'make check' problem or if what I have is NFG. Ted Running in noclean mode. Mistakes will not be cleaned up. The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. creating directory /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data... ok creating directory /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data/base... ok creating directory /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data/global... ok creating directory /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data/pg_xlog... ok creating directory /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data/pg_clog... ok selecting default shared_buffers... 200 selecting default max_connections... 30 creating configuration files... ok creating template1 database in /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data/base/1... FATAL: could not create shared memory segment: Invalid argument DETAIL: Failed syscall was shmget(key=1, size=10444800, 03600). HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 10444800 bytes), reduce PostgreSQL's shared_buffers parameter (currently 1000) and/or its max_connections parameter (currently 100). If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for. The PostgreSQL documentation contains more information about shared memory configuration. initdb: failed initdb: data directory "/Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data" not removed at user's request __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] making 7.4 beta2 on Mac OS x
I is not a bug. Its just your OSX is too conservative regarding IPC defaults. Consider changing these variables: kern.ipc.shmmax kern.ipc.shm_use_phys (for performance only) kern.ipc.shmall They apply to FreeBSD, but OSX must have something similar. On Tue, 16 Sep 2003, Theodore Petrosky wrote: > I thought I would try to make 7.4beta2 on my os X > machine. I used the default ./configure then make. > make says everything is ok to install so I tried a > make check.. this is my error log. > > gcc is set for 3.1 > os X 10.2.6. > > I don't know if this is just a 'make check' problem or > if what I have is NFG. > > Ted > > > Running in noclean mode. Mistakes will not be cleaned > up. > The files belonging to this database system will be > owned by user "postgres". > This user must also own the server process. > > The database cluster will be initialized with locale > C. > > creating directory > /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data... > ok > creating directory > /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data/base... > ok > creating directory > /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data/global... > ok > creating directory > /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data/pg_xlog... > ok > creating directory > /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data/pg_clog... > ok > selecting default shared_buffers... 200 > selecting default max_connections... 30 > creating configuration files... ok > creating template1 database in > /Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data/base/1... > FATAL: could not create shared memory segment: > Invalid argument > DETAIL: Failed syscall was shmget(key=1, > size=10444800, 03600). > HINT: This error usually means that PostgreSQL's > request for a shared memory segment exceeded your > kernel's SHMMAX parameter. You can either reduce the > request size or reconfigure the kernel with larger > SHMMAX. To reduce the request size (currently 10444800 > bytes), reduce PostgreSQL's shared_buffers parameter > (currently 1000) and/or its max_connections parameter > (currently 100). > If the request size is already small, it's possible > that it is less than your kernel's SHMMIN parameter, > in which case raising the request size or > reconfiguring SHMMIN is called for. > The PostgreSQL documentation contains more information > about shared memory configuration. > > initdb: failed > initdb: data directory > "/Users/postgres/postgres/postgresql-7.4beta2/src/test/regress/./tmp_check/data" > not removed at user's request > > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings > -- == Achilleus Mantzios S/W Engineer IT dept Dynacom Tankers Mngmt Nikis 4, Glyfada Athens 16610 Greece tel:+30-210-8981112 fax:+30-210-8981877 email: achill at matrix dot gatewaynet dot com mantzios at softlab dot ece dot ntua dot gr ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] making 7.4 beta2 on Mac OS x
Achilleus Mantzios <[EMAIL PROTECTED]> writes: > I is not a bug. Yes it is; it's fixed in beta3. > Its just your OSX is too conservative regarding > IPC defaults. PG knows that, but we made a last-minute change in beta2 that caused the later part of the initdb process to forget to use the numbers that the earlier part determined. Please check that beta3 works *without* upping your shmmax. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] beta 3 and OS X
Contrats. Macintosh OS X 10.2.6 gcc 3.1 make check completes with 0 (zero) errors... Ted __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] 7.3.2 incorrectly counts characters for unicode varchar field
Attached is the UTF-8 encoded sql file in case it got messed up in the mail
transfer.
And here it is pasted in directly from the window that was displaying
chinese characters.
insert into mgc values ('分钟练习分钟练习练习');
Looking at the UTF-8 documentation, 10 chinese characters could be any
number of bytes, each character being say 2 or 3 characters.
Matty.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Matthew Cooper" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, September 13, 2003 5:51 PM
Subject: Re: [BUGS] 7.3.2 incorrectly counts characters for unicode varchar
field
> > insert into mgc values ('Ã¥Ë?â? éâ?TŸç»Æ'ä¹ Ã¥Ë?â?
éâ?TŸç»Æ'ä¹ ç»Æ'ä¹ ');
>
> I don't think this string is correctly unicode-encoded. Anyway "length"
> claims it is 30 characters.
>
> regards, tom lane
>
mgc.sql
Description: Binary data
---(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] 7.3.2 incorrectly counts characters for unicode varchar field
Doh! It looks like its time to eat humble pie. It turns out that the guy
here who has 7.3.4 and helped me to reproduce the problem did not follow our
own installation instructions (that he recently re-worded!) as follows:
"createdb -E UNICODE -U DB_USER -P DB_PASSWORD DB_NAME"
and did not set the encoding. I, like a good boy, did on my 7.2
installation. The guys I am trying to debug the problem for are in another
location and are using 7.3.4 too. Hence I narrowed it down to a version
problem. I am asking them to check the encoding on their database too and
will post back with huge apologies and thanks for your time when they
inevitably confirm that the encoding is SQL_ANSI.
Thanks, Matty.
- Original Message -
From: "Matthew Cooper" <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, September 15, 2003 9:50 AM
Subject: Re: [BUGS] 7.3.2 incorrectly counts characters for unicode varchar
field
> Attached is the UTF-8 encoded sql file in case it got messed up in the
mail
> transfer.
>
> And here it is pasted in directly from the window that was displaying
> chinese characters.
>
> insert into mgc values ('分钟练习分钟练习练习');
>
>
> Looking at the UTF-8 documentation, 10 chinese characters could be any
> number of bytes, each character being say 2 or 3 characters.
>
> Matty.
> - Original Message -
> From: "Tom Lane" <[EMAIL PROTECTED]>
> To: "Matthew Cooper" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Saturday, September 13, 2003 5:51 PM
> Subject: Re: [BUGS] 7.3.2 incorrectly counts characters for unicode
varchar
> field
>
>
> > > insert into mgc values ('Ã¥Ë?â? éâ?TŸç»Æ'ä¹ Ã¥Ë?â?
> éâ?TŸç»Æ'ä¹ ç»Æ'ä¹ ');
> >
> > I don't think this string is correctly unicode-encoded. Anyway "length"
> > claims it is 30 characters.
> >
> > regards, tom lane
> >
>
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
