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
Re: [BUGS] Date or Documentation bug?
Mitterwald, Holger writes: > I am not shure if I discovered a Date or a Documentation bug The > Manpage says if postgres is started with the option "-e" it uses > european date-style in the format "dd-mm-". But this only takes > effekt if I select datestyle=Postgres instead of the default "ISO". > With Datestyle=ISO it is always "-mm-dd", no matter if I choose US > or European style. With this behavior the postgres option "-e" does > rather make any sense to me. The documentation is kind of unclear at that point. The European/NonEuropean option (-e) controls 1) Whether the month is before the day or vice versa in the 'SQL' and 'Postgres' styles. 2) How ambiguous date input (e.g., 01/02/99) is to be interpreted regarding month before day. It does not affect the output of the ISO format, since the ISO format is fixed. > P.S.: Is there a way to change the Datestyle to Postgres without a > SQL-Statement, e.g. ENV-Variable or config-file? PGDATESTYLE environment variable. Config file I'm working on. -- Peter Eisentraut Sernanders väg 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/Sweden
Re: [BUGS] Some problem with inet type on PostgreSQL-7.0
I can confirm your problem but there's no known fix. The truth is that the inet/cidr types have quite a number of bogosities but no one understands them well enough to undertake fixing them. Vadim Passynkov writes: > Hi All, > > I have some problem with inet type on PostgreSQL-7.0 (FreeBSD > 3.4-STABLE) > > Table "ipaddresses" > Attribute | Type | Modifier > --+-+ > sysname | text| not null > index| integer | not null > ip_addr | inet| not null > > Indices: ipaddresses_ip_addr, > ipaddresses_pkey > > (sysname, ip_addr) - PRIMARY KEY > > View "ipaddresses_view" > Attribute | Type | Modifier > --+-+-- > sysname | text| > index| integer | > ip_addr | inet| > ip_netmask | inet| > > View definition: SELECT ipaddresses.sysname, ipaddresses."index", > ipv4_host(ipaddresses.ip_addr) AS ip_addr, > ipv4_netmask(ipaddresses.ip_addr) AS ip_netmask FROM ipaddresses; > > > ipv4_host and ipv4_netmask like original host and netmask but return > inet type ( need for ORDER ) > > CREATE FUNCTION ipv4_host(inet) RETURNS inet AS ' > BEGIN > RETURN host($1); > END; > ' LANGUAGE 'plpgsql'; > > CREATE FUNCTION ipv4_netmask(inet) RETURNS inet AS ' > BEGIN > RETURN netmask($1); > END; > ' LANGUAGE 'plpgsql'; > > > Problem > > select * from ipaddresses where sysname = 'switch01.tor'; >sysname| index | ip_addr > --+---+-- > switch01.tor | 1 | 127.0/8 > switch01.tor | 2 | 127.0/8 > switch01.tor | 3 | 209.250.155.8/27 > (2 rows) > > but (sysname, ip_addr) - PRIMARY KEY > > 127.0/8 - it's not correct output ( real 127.0.0.2/8 and 127.0.0.3/8) > > select * from ipaddresses_view where sysname = 'switch01.tor'; >sysname| index |ip_addr| ip_netmask > --+---+---+- > switch01.tor | 1 | 127.0.0.2 | 255.0.0.0 > switch01.tor | 2 | 127.0.0.3 | 255.0.0.0 > switch01.tor | 3 | 209.250.155.8 | 255.255.255.224 > (2 rows) > > > 127.0.0.2 | 255.0.0.0 and 127.0.0.3 | 255.0.0.0 - it's correct output > > And of course after pg_dump and restore correct value 127.0.0.2/8 and > 127.0.0.3/8 will lose > and will have problem with PRIMARY KEY - (sysname, ip_addr). > > -- Peter Eisentraut Sernanders väg 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/Sweden
