[BUGS] netmask(inet) function broken in 7.4

[Joe Sunday]

POSTGRESQL BUG REPORT TEMPLATE



Your name   :   Joe Sunday
Your email address  :   [EMAIL PROTECTED]


System Configuration
-
  Architecture (example: Intel Pentium) : UltraSparc II

  Operating System (example: Linux 2.0.26 ELF)  : Solaris 9

  PostgreSQL version (example: PostgreSQL-7.4):   PostgreSQL-7.4

  Compiler used (example:  gcc 2.95.2)  : gcc 2.95.3


Please enter a FULL description of your problem:

After upgrading to 7.4 from 7.3.4, the behaviour of the netmask(inet) function changed,
but the documentation still specifies the old behaviour (which seems more correct than 
the
new version)

Old:
netmask( '192.168.1.0/23' ) returns '255.255.254.0'

New:
netmask( '192.168.1.0/23' ) returns '255.255.254.0/23'

Please describe a way to repeat the problem.   Please try to provide a
concise reproducible example, if at all possible: 
--

Perform a SELECT using the netmask function with the example above.

If you know how this problem might be fixed, list the solution below:
-
Revert netmask to the prior behaviour, or update the documentation to match the new
behaviour. Masklen(inet) already returns just the mask length for CIDR-style 
addressing,
netmask(inet) should just return a mask without the redundant length.

-- 
Joe Sunday <[EMAIL PROTECTED]>  http://www.csh.rit.edu/~sunday/
Computer Science House, Rochester Inst. Of Technology

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [BUGS] Repeatedly breaking indexes - SOLVED

[Martin Edlman]

Hello,

finally the problem is solved. The problem was with locales.

I installed and initialised the database under cs_CZ, so Pg 
recorded cs_CZ in all its configurations and startup scripts.
After that I changed /etc/sysconfig/i18n to use en_US locale as 
system default.
And that was the problem. According to "ps axe" the postmaster was 
running under en_US locales instead of cs_CZ as I expected.
So I changed /etc/sysconfig/i18n to use cs_CZ and everything is ok 
from then. All indexes seem to be working fine and there are no problems.

But I would like to know why it was not started under cs_CZ when 
all Pg config files specify cs_CZ and ~postgres/.bash_profile contains
export LANG="cs_CZ" and postmaster is run from it's rc script as

su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl  -D $PGDATA "

So I expected that cs_CZ will be used in this case. :-( GRr.

Ok now it's working, thank you all who helped.

Martin

> Tomas Szepe <[EMAIL PROTECTED]> writes:
> > Martin, you can probably rule out the cs_CZ (LATIN2) locale as the cause
> > of your problems -- I've been using that one for years on many production
> > postgres systems (often huge and constantly loaded) and have never observed
> > the problems you're describing.
> 
> Thanks for the info.  But are you using cs_CZ.ISO8859-2 in particular on
> Red Hat 8.0 in particular?  If it is a locale-related issue, it might be
> specific to that particular variant on that platform.
> 
> I have RH 8.0 here, and could easily run some tests, but I'm not sure
> what to look for.  A quick run of the regression tests didn't reveal
> any issues, other than expectable differences from C locale in sort
> ordering.
> 
>   regards, tom lane
> 

-- 

Martin Edlman
Fortech s.r.o, Litomysl
Public PGP key: http://edas.visaci.cz/#keys


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster