date:20071109


Sajan S wrote:

We are working on MapServer with postgresql-8.1.8 on
fedora core 4. The geometry data type is not available in the linux version
of PostgreSQL. In postgresql 8.0.0beta5(windows version ) the  geometry data
type is available, which we use on our Windows machine. But it is not
available for linux in the newer version of postgresql also. Kindly suggest
some alternates for this so that we can proceed with our work.


What data type are you talking about? There is no data type called 
"geometry" in 8.0 either.


There is a bunch of geometric data types, described in Section 8.7 of 
the manual:


http://www.postgresql.org/docs/8.1/static/datatype-geometric.html

but there hasn't been any significant changes to them between 8.0 and 8.1.

Are you perhaps using PostGIS? In that case, you need to install the 
PostGIS extension separately, like you did for 8.0. Please refer to the 
PostGIS documentation for further details on that.


Ps. The most recent release of the 8.1-series is 8.1.10. Also, there's 
significant improvements to the Windows port in 8.2. You should consider 
upgrading.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

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

Re: [BUGS] BUG #3730: Creating a swedish dictionary fails

2007-11-09 Thread Penty Wenngren

On Thu, Nov 08, 2007 at 08:45:32PM -0500, Tom Lane wrote:
> Penty Wenngren <[EMAIL PROTECTED]> writes:
> > On Thu, Nov 08, 2007 at 05:21:17PM -0500, Tom Lane wrote:
> >> I suspect you are working in a locale that doesn't think Ã is a
> >> letter --- check lc_ctype.
> 
> > It doesn't seem to make any difference. The first try was done from a
> > terminal that didn't care much for UTF-8, but that is fixed now and I
> > still get the same result.
> 
> It sorta looks to me like you only changed the locale of your terminal
> session.  Changing the database's locale requires re-initdb.  What
> does "show lc_ctype" show within Postgres?
> 

test=# show lc_ctype;
  lc_ctype   
-
 sv_SE.UTF-8
(1 rad)

The database was initialized with encoding set to UTF8 and locale set to
sv_SE.UTF8.

If you are confident that this is not a PostgreSQL bug, I'll accept that
happily and move on to do some more testing on my end.

// Penty

-- 

Penty Wenngren
DGC Solutions AB

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

[BUGS] BUG #3732: Select returns 0 rows for varchar field

2007-11-09 Thread George Woodman


The following bug has been logged online:

Bug reference:  3732
Logged by:  George Woodman
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system:   Windows 2000
Description:Select returns 0 rows for varchar field
Details: 

I created a table with the following specs.
CREATE TABLE user_control
(
  uci character varying(10) NOT NULL,
  ucname character varying(20),
  ucpwd character varying(10),
  ucrole character varying(20),
  CONSTRAINT user_control_pkey PRIMARY KEY (uci)
)
WITH (OIDS=FALSE);
ALTER TABLE user_control OWNER TO postgres;
GRANT ALL ON TABLE user_control TO postgres;

I have 2 records with the following details:
george,George,george,developer
1234567890,Temp,0,developer
When I try to retrieve this record with the following statement from a
ASP.Net (VB) app I get no rows returned.
Select * from user_control where uci = 'george'
However this statement works.
Select * from user_control where uci = '1234567890'

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [BUGS] BUG #3731: ash table "PROCLOCK hash" corrupted

2007-11-09 Thread Daniel Cristian Cruz

Em Qui, 2007-11-08 às 12:29 -0500, Tom Lane escreveu:
> "Daniel Cristian Cruz" <[EMAIL PROTECTED]> writes:
> > A few moments ago I got the following message, but didn't found any
> > reference on the internet (including lists).
> 
> > Nov  8 13:50:56 SERVER postgres[18874]: [5-1] user=XXX,db=XXXPANIC:  hash
> > table "PROCLOCK hash" corrupted
> 
> > The error showed after some query that where logged because were slow (more
> > than 5 seconds), in which they had a very big list of values in a NOT IN
> > clause (not sure if this caused the problem).
> 
> > I don't know if this is a bug or not.
> 
> Well, it shouldn't have happened, so either it's a bug or you had a
> hardware glitch.  But unless you can find a way to reproduce it I'm
> not sure we can do much about it.  I doubt your large NOT IN was
> relevant --- more likely it'd be something associated with inter-process
> interactions.

It was the first time I saw the message. Never seen it again. I've tried
to reproduce, but it didn't worked.

-- 
Daniel Cristian Cruz
Analista de Sistemas - Administrador de Banco de Dados
SENAI/SC  - Servico Nacional de Aprendizagem Industrial
NTI - Núcleo de Tecnologia da Informação
Fone: (48) 3239-1422


---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [BUGS] BUG #3728: pthread autoconf hangs

2007-11-09 Thread Zdenek Kotala

heasley wrote:

Thu, Nov 08, 2007 at 11:04:01AM +0100, Zdenek Kotala:

heasley napsal(a):

The configure is via NetBSD's pkgsrc system.

./configure --sysconfdir=/usr/pkg/etc/postgresql --datadir=/usr/pkg/share/po
stgresql --with-docdir=/usr/pkg/share/doc/postgresql --with-template=solaris --w
ithout-readline --without-zlib --enable-nls --without-java --without-perl --with
out-python --without-tcl --with-openssl --with-readline --with-zlib --enable-thr
ead-safety --with-libiconv-prefix=/usr/pkg --with-libintl-prefix=/usr/pkg --pref
ix=/usr/pkg --host=sparc-sun-solaris2 --mandir=/usr/pkg/man

It is really strange configure. See --with-readline/--without-readline.
Unfrotunately I currently does not have system with S9 similar to yours
configuration :(. I tested Sun Studio compiler with following configure
switch ./configure --without-readline --enable-thread-safety and it
works fine. Can you try Sun studio?

http://developers.sun.com/sunstudio/downloads/thankyou.jsp?submit=%A0FREE+Download%A0%BB%A0

from config.log:
CFLAGS=-g -static-libgcc -static-libgcc -D_LARGEFILE64_SOURCE -mcpu=v9
-mtune=ultrasparc -m64 -D__sparc_v9__ -pipe -I/usr/pkg/include -I/usr/include
-Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing

Can you try build it as 32bit application? If there is not problem with
64bit libraries.

www.shrubbery.net/~heas/pg_config.log.txt
www.shrubbery.net/~heas/conftest.c.txt

I built gcc 4.1, after having some difficulty with other versions. It is a
fairly straight forward build, expect that it has a hack to avoid a libiconv
bug and is within a wrapper script that forces 64-bit options. I did not have
this problem with pre-8.1.5 postgres as I recall; 8.1.4 built fine and I do
not believe there have been any pkgsrc changes that would affect this.

I don't see any difference in ./configure related to pthread. Do you use
same process for building? Do you have same version of all libraries,
GCC or did you update some version? Can you compile 8.1.4 with same
configuration?

It seems to me that it could be something wrong with your GCC compilation.

Zdenek

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: [BUGS] BUG #3732: Select returns 0 rows for varchar field


George Woodman wrote:

I created a table with the following specs.
CREATE TABLE user_control
(
  uci character varying(10) NOT NULL,
  ucname character varying(20),
  ucpwd character varying(10),
  ucrole character varying(20),
  CONSTRAINT user_control_pkey PRIMARY KEY (uci)
)
WITH (OIDS=FALSE);
ALTER TABLE user_control OWNER TO postgres;
GRANT ALL ON TABLE user_control TO postgres;

I have 2 records with the following details:
george,George,george,developer
1234567890,Temp,0,developer
When I try to retrieve this record with the following statement from a
ASP.Net (VB) app I get no rows returned.
Select * from user_control where uci = 'george'
However this statement works.
Select * from user_control where uci = '1234567890'


Works for me. Make sure there's no trailing spaces when you insert the data.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [BUGS] BUG #3730: Creating a swedish dictionary fails

Penty Wenngren wrote:

> If you are confident that this is not a PostgreSQL bug, I'll accept that
> happily and move on to do some more testing on my end.

I don't think it has been shown that this is not our bug.  I reproduced
your problem here on an UTF8 environment and it does fail for me.
On the other hand, I am unsure how to test whether Ö is letter here, but
at least lower() works on it:

alvherre=# select lower('Ö');
 lower 
---
 ö
(1 fila)

alvherre=# show lc_ctype ;
  lc_ctype  

 sv_SE.utf8
(1 fila)

-- 
Alvaro Herrera   Valdivia, Chile   ICBM: S 39Âº 49' 18.1", W 73Âº 13' 56.4"
Management by consensus: I have decided; you concede.
(Leonard Liu)

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] BUG #3730: Creating a swedish dictionary fails

2007-11-09 Thread Magnus Hagander


On Fri, 2007-11-09 at 10:27 -0300, Alvaro Herrera wrote:
> Penty Wenngren wrote:
> 
> > If you are confident that this is not a PostgreSQL bug, I'll accept that
> > happily and move on to do some more testing on my end.
> 
> I don't think it has been shown that this is not our bug.  I reproduced
> your problem here on an UTF8 environment and it does fail for me.
> On the other hand, I am unsure how to test whether Ö is letter here, but
> at least lower() works on it:

Not sure exactly what you mean, but Ö certainly is a letter, and ö is
the lowercase of it, so that part looks correct.

//Magnus

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

[BUGS] BUG #3735: Can't create xml-stylesheet processing instruction

2007-11-09 Thread Ben Leslie


The following bug has been logged online:

Bug reference:  3735
Logged by:  Ben Leslie
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.3 beta 2
Operating system:   Mac OS X
Description:Can't create xml-stylesheet processing instruction
Details: 

# select xmlpi(name "xml-stylesheet");
ERROR:  invalid XML processing instruction
DETAIL:  XML processing instruction target name cannot start with "xml".

The w3c XML 1.0 spec says that PIs starting with 'xml' are reserved.

(http://www.w3.org/TR/REC-xml/#sec-pi)

However the w3c stylesheet recommendation
(http://www.w3.org/TR/xml-stylesheet/) specifies a xml-stylesheet processing
instruction, so it would be useful to be able to handle this.

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [BUGS] BUG #3730: Creating a swedish dictionary fails

Tom Lane wrote:
> Penty Wenngren <[EMAIL PROTECTED]> writes:
> > I used iconv to convert svenska.aff and svenska.datalist (from
> > iswedish-1.2.1) to UTF-8. The converted files can be found at:
> > http://www.lederhosen.org/swedish.affix
> > http://www.lederhosen.org/swedish.dict
> 
> I think the reason it's failing right there is that that line is the
> first affix rule containing a non-ASCII letter, and the rules are
> supposed to only contain letters and certain specific punctuation.
> I suspect you are working in a locale that doesn't think Ã is a
> letter --- check lc_ctype.

I patched parse_affentry to report the current token and I see this:

alvherre=# CREATE TEXT SEARCH DICTIONARY swedish_ispell (
TEMPLATE = ispell,
DictFile = swedish,
AffFile = swedish,
StopWords = swedish);
ERROR:  syntax error at line 149 (str: "örs
") of affix file 
"/home/alvherre/Code/CVS/pgsql/install/00orig/share/tsearch_data/swedish.affix"

I am wondering if the newline being included in the token could be
causing a problem.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[BUGS] Revisiting BUG #3684: After dump/restore, schema PUBLIC always exists

2007-11-09 Thread Pedro Gimeno



Since I received no feedback, I think this may have been dismissed as  
"not a bug". Here are further arguments on why I believe it's a bug:


(The following assumes that schema "public" was dropped from the target  
database prior to the dump.)


-Creating a dump (following section 23.1 of the 8.2 manual) and then  
restoring it (following 23.1.1) causes schema "public" to reappear.  
This is not mentioned anywhere in section 23.1. Instead the  
documentation says that "The dumps produced by pg_dump are relative to  
template0." There's no mention that objects which are preexisting in  
template0 will still exist after the restore. I believe this to be a  
documentation bug, as it's usually assumed that the purpose of a backup  
is to be able to get things to the exact same state as they were when  
it was created.


-If the administrator is unaware of the existence of schema "public"  
after the restore, the security risk that the existence of this schema  
poses is similar to that of CVE-2007-2138, but worse since functions  
and operators will also be searched for in the "public" schema.


For these reasons, I suggest that pg_dump includes a 'DROP SCHEMA  
public' command in case it exists in template0 and doesn't in the  
database being dumped, if the schema is to be part of the dump (option  
-s or no option). Maybe other objects should be dropped too.


It can be argued that to be 'destructive' so it's better to leave it  
out. The only way I think it can be considered destructive is if  
adjustments are made to the public schema prior to the restore, and  
those adjustments are expected to be there afterwards. If that's the  
general feeling, at least the DROP command could be included when -C is  
used in pg_dump and either commented out or not included at all  
otherwise.


As it is now, I can think only of three possible workarounds:

-To always remember to drop schema "public" after restoring. A  
prerequisite is to be aware that it will exist.


-To leave it created instead of dropping it, but issue a REVOKE ALL ON  
SCHEMA public FROM PUBLIC, so that it's adjusted to not have all  
privileges on restore.


-To drop it from template0. This is a disaster if installing software  
that expects it to exist in template0.


Only the second workaround mentioned is acceptable for us, but it still  
feels like a dirty hack. That's why I'd like to see this fixed.


-- Pedro Gimeno

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

Re: [BUGS] BUG #3732: Select returns 0 rows for varchar field

George Woodman wrote:

> I have 2 records with the following details:
> george,George,george,developer
> 1234567890,Temp,0,developer
> When I try to retrieve this record with the following statement from a
> ASP.Net (VB) app I get no rows returned.
> Select * from user_control where uci = 'george'
> However this statement works.
> Select * from user_control where uci = '1234567890'

Are you sure 'george' does not have whitespace at the end?  My bet is
that it is actually 'george'

-- 
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"Postgres is bloatware by design: it was built to house
 PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)

---(end of broadcast)---
TIP 6: explain analyze is your friend

[BUGS] BUG #3734: Invalid XML schema output.

2007-11-09 Thread Ben Leslie


The following bug has been logged online:

Bug reference:  3734
Logged by:  Ben Leslie
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.3 beta2
Operating system:   Mac OS X
Description:Invalid XML schema output.
Details: 

database_to_xml_and_xmlschema creates an invalid XML in certain
circumstances.

To recreate:

CREATE DATABASE test;
\c test
CREATE DOMAIN isoweek AS date CHECK (date_trunc('week', VALUE) = VALUE);
CREATE TABLE test (x isoweek);
INSERT INTO test VALUES ('2007-01-01');

Now to see the bug:

SELECT database_to_xml_and_xmlschema('t', 'f', '');

The output is:

 http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="#">
 
 http://www.w3.org/2001/XMLSchema";>
 
 
   
 
 
 
   
 
   
 
 
 
   
 
   
 
 
 
 
 
 
 
 
 
 
 
   2007-01-01
 
 
 
 
 
 
 


The specific problem is that the following is malformed; the xsd:restriction
tag is never closed.

 
   
 

The correct output (as far as I can tell) should be:

 
   
 

---(end of broadcast)---
TIP 1: 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] BUG #3735: Can't create xml-stylesheet processing instruction

2007-11-09 Thread Peter Eisentraut

Am Freitag, 9. November 2007 schrieb Ben Leslie:
> # select xmlpi(name "xml-stylesheet");
> ERROR:  invalid XML processing instruction
> DETAIL:  XML processing instruction target name cannot start with "xml".

Apparently I read the SQL spec a bit to strictly here.  I've installed a fix 
into CVS.

> The w3c XML 1.0 spec says that PIs starting with 'xml' are reserved.

That's what I thought as well, but they actually only reserve names being 
exactly 'xml' modulo case differences.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: 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] BUG #3736: server cannot listen

2007-11-09 Thread Derek


The following bug has been logged online:

Bug reference:  3736
Logged by:  Derek
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1.10
Operating system:   Windows XP Professional
Description:server cannot listen
Details: 

when i try to connect to the postgreSQL database i get this error message:
Server doesn't listen
The server doesn't accept connections: the connection library reports 
could not connect to server: Connection refused (0x274D/10061) Is the
server running on host "127.0.0.1" and accepting TCP/IP connections on port
5432? 
If you encounter this message, please check if the server you're trying to
contact is actually running PostgreSQL on the given port. Test if you have
network connectivity from your client to the server host using ping or
equivalent tools. Is your network / VPN / SSH tunnel / firewall configured
correctly? 
For security reasons, PostgreSQL does not listen on all available IP
addresses on the server machine initially. In order to access the server
over the network, you need to enable listening on the address first. 
For PostgreSQL servers starting with version 8.0, this is controlled using
the "listen_addresses" parameter in the postgresql.conf file. Here, you can
enter a list of IP addresses the server should listen on, or simply use '*'
to listen on all available IP addresses. For earlier servers (Version 7.3 or
7.4), you'll need to set the "tcpip_socket" parameter to 'true'. 
You can use the postgresql.conf editor that is built into pgAdmin III to
edit the postgresql.conf configuration file. After changing this file, you
need to restart the server process to make the setting effective. 
If you double-checked your configuration but still get this error message,
it's still unlikely that you encounter a fatal PostgreSQL misbehaviour. You
probably have some low level network connectivity problems (e.g. firewall
configuration). Please check this thoroughly before reporting a bug to the
PostgreSQL community.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[BUGS] BUG #3737: lower/upper fails to match extended chars in LATIN1

2007-11-09 Thread Jonas Forsman


The following bug has been logged online:

Bug reference:  3737
Logged by:  Jonas Forsman
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1.10
Operating system:   Ubuntu 6.06 LTS
Description:lower/upper fails to match extended chars in  LATIN1
Details: 

Try:
select * from table where lower(address) like '%Ã¥%'

This select fails to find addresses including capital Ã and similars in
LATIN1 (like Ã, Ã, Ã). 

The same bug is valid for upper.

---(end of broadcast)---
TIP 6: explain analyze is your friend

[BUGS] BUG #3738: psql crashes on exit.

2007-11-09 Thread Chris Vickery


The following bug has been logged online:

Bug reference:  3738
Logged by:  Chris Vickery
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system:   OS X 10.4
Description:psql crashes on exit.
Details: 

senate=# \q
psql(4484) malloc: *** error for object 0x1806200: incorrect checksum for
freed object - object was probably modified after being freed, break at
szone_error to debug
psql(4484) malloc: *** set a breakpoint in szone_error to debug
Segmentation fault

The problem didn't always occur, and I cannot say what caused it to start
happening. But it happens every time now. I have sometimes been running the
current version of pgAdmin3 concurrently with psql, if that's a clue.

The problem started when running 8.2.4, so I backed up the database (using
dumpall from 8.2.4), upgraded to 8.2.5, and restored the database: same
problem. The above output is from the first run of psql after the upgrade; I
have not run pgAdmin3 since the upgrade. 

"szone_error" is an OS X library routine, but I'm not enough of an OS X
developer to know how to get at it.

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] BUG #3737: lower/upper fails to match extended chars in LATIN1


Jonas Forsman wrote:

The following bug has been logged online:

Bug reference:  3737
Logged by:  Jonas Forsman
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1.10
Operating system:   Ubuntu 6.06 LTS
Description:lower/upper fails to match extended chars in  LATIN1
Details: 


Try:
select * from table where lower(address) like '%Ã¥%'

This select fails to find addresses including capital Ã… and similars in
LATIN1 (like Ã…, Ã„, Ã–). 


The behavior of lower() depends on your locale. What locale are you 
running in? Make sure your locale matches the encoding.


Exact locale names and behavior are defined by the operating system, but 
for example on Debian, which is probably the same as Ubuntu in this 
case, use


initdb -D data --locale=sv_SE.iso88591 --encoding=LATIN1

for Swedish.

Also make sure that your client_encoding is set correctly. For example, 
if you run the query in psql in a terminal that uses UTF-8 encoding, you 
need to "SET client_encoding='UTF-8'"


See the manual for more details: 
http://www.postgresql.org/docs/8.1/static/charset.html#LOCALE


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [BUGS] BUG #3736: server cannot listen

2007-11-09 Thread Douglas Toltzman

Have you checked your PostgreSQL configuration?  Have you checked  
your firewall?  Did you read the last line of the text you posted,  
where it says "Please check this thoroughly before reporting a bug to  
the PostgreSQL community" ?


I give kudos to the support team for being very tolerant and  
patient.  Please don't blame them for my saying this is probably a  
system configuration error, and if you had bothered to read the  
message, or the installation guide, you would not be reporting a bug.



On Nov 9, 2007, at 4:18 PM, Derek wrote:



The following bug has been logged online:

Bug reference:  3736
Logged by:  Derek
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1.10
Operating system:   Windows XP Professional
Description:server cannot listen
Details:

when i try to connect to the postgreSQL database i get this error  
message:

Server doesn't listen
The server doesn't accept connections: the connection library reports
could not connect to server: Connection refused (0x274D/10061)  
Is the
server running on host "127.0.0.1" and accepting TCP/IP connections  
on port

5432?
If you encounter this message, please check if the server you're  
trying to
contact is actually running PostgreSQL on the given port. Test if  
you have

network connectivity from your client to the server host using ping or
equivalent tools. Is your network / VPN / SSH tunnel / firewall  
configured

correctly?
For security reasons, PostgreSQL does not listen on all available IP
addresses on the server machine initially. In order to access the  
server

over the network, you need to enable listening on the address first.
For PostgreSQL servers starting with version 8.0, this is  
controlled using
the "listen_addresses" parameter in the postgresql.conf file. Here,  
you can
enter a list of IP addresses the server should listen on, or simply  
use '*'
to listen on all available IP addresses. For earlier servers  
(Version 7.3 or

7.4), you'll need to set the "tcpip_socket" parameter to 'true'.
You can use the postgresql.conf editor that is built into pgAdmin  
III to
edit the postgresql.conf configuration file. After changing this  
file, you

need to restart the server process to make the setting effective.
If you double-checked your configuration but still get this error  
message,
it's still unlikely that you encounter a fatal PostgreSQL  
misbehaviour. You
probably have some low level network connectivity problems (e.g.  
firewall
configuration). Please check this thoroughly before reporting a bug  
to the

PostgreSQL community.

---(end of  
broadcast)---

TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Douglas Toltzman
[EMAIL PROTECTED]
(910) 526-5938

Re: [BUGS] Revisiting BUG #3684: After dump/restore, schema PUBLIC always exists

Pedro Gimeno <[EMAIL PROTECTED]> writes:
> ... it's usually assumed that the purpose of a backup  
> is to be able to get things to the exact same state as they were when  
> it was created.

The hole in your argument is that this is not so.  The purpose of a
backup is to get the *user's* objects into the same state they were in.
If we applied that reasoning to *system* objects then presumably loading
a dump from an 8.2 database into 8.3 would magically destroy all the new
features in 8.3 (eg all the text search objects).

It might be that the public schema should be considered a user object
not a system object, but you need to make a case specifically about
that, not argue that the behavior is broken in general.

What I would personally suggest is that rather than insisting on public
not being there, you just do
revoke create on schema public from public;
which is a property that pg_dump *will* preserve.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] BUG #3738: psql crashes on exit.

"Chris Vickery" <[EMAIL PROTECTED]> writes:
> Description:psql crashes on exit.

We've seen this before --- there's a bug in the Apple-supplied libedit:
http://archives.postgresql.org/pgsql-hackers/2006-12/msg01222.php

My suggestion would be to rebuild using libreadline, which is a lot more
featureful anyway.  If you don't want to do that, removing
~/.psql_history will make it go away (for awhile).

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [BUGS] Revisiting BUG #3684: After dump/restore, schema PUBLIC always exists

2007-11-09 Thread Bruce Momjian

Pedro Gimeno wrote:
> 
> Since I received no feedback, I think this may have been dismissed as  
> "not a bug". Here are further arguments on why I believe it's a bug:
> 
> (The following assumes that schema "public" was dropped from the target  
> database prior to the dump.)
> 
> -Creating a dump (following section 23.1 of the 8.2 manual) and then  
> restoring it (following 23.1.1) causes schema "public" to reappear.  
> This is not mentioned anywhere in section 23.1. Instead the  
> documentation says that "The dumps produced by pg_dump are relative to  
> template0." There's no mention that objects which are preexisting in  
> template0 will still exist after the restore. I believe this to be a  
> documentation bug, as it's usually assumed that the purpose of a backup  
> is to be able to get things to the exact same state as they were when  
> it was created.
> 
> -If the administrator is unaware of the existence of schema "public"  
> after the restore, the security risk that the existence of this schema  
> poses is similar to that of CVE-2007-2138, but worse since functions  
> and operators will also be searched for in the "public" schema.
> 
> For these reasons, I suggest that pg_dump includes a 'DROP SCHEMA  
> public' command in case it exists in template0 and doesn't in the  
> database being dumped, if the schema is to be part of the dump (option  
> -s or no option). Maybe other objects should be dropped too.
> 
> It can be argued that to be 'destructive' so it's better to leave it  
> out. The only way I think it can be considered destructive is if  
> adjustments are made to the public schema prior to the restore, and  
> those adjustments are expected to be there afterwards. If that's the  
> general feeling, at least the DROP command could be included when -C is  
> used in pg_dump and either commented out or not included at all  
> otherwise.
> 
> As it is now, I can think only of three possible workarounds:
> 
> -To always remember to drop schema "public" after restoring. A  
> prerequisite is to be aware that it will exist.
> 
> -To leave it created instead of dropping it, but issue a REVOKE ALL ON  
> SCHEMA public FROM PUBLIC, so that it's adjusted to not have all  
> privileges on restore.
> 
> -To drop it from template0. This is a disaster if installing software  
> that expects it to exist in template0.
> 
> Only the second workaround mentioned is acceptable for us, but it still  
> feels like a dirty hack. That's why I'd like to see this fixed.

The fact is that 'public' is created from template1, so I suppose if you
remove it from there then new databases will not have it.  

I think it would be odd for pg_dump to remove something that was in the
database before the restore started.  I am afraid removing it yourself
is the only logical option for us.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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

Re: [BUGS] BUG #3737: lower/upper fails to match extended chars in LATIN1


Jonas Forsman wrote:

it is possibly a locale-error. may I ask:
1. How do I check the locale?


Within psql:

show lc_ctype; (and other lc_* variables as well)
show server_encoding;
show client_encoding;


2. Can I change this on already running db:s ?


Unfortunately you can't. You'll have to re-initdb. :-(

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [BUGS] BUG #3730: Creating a swedish dictionary fails

Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I am wondering if the newline being included in the token could be
> causing a problem.

Nope.  I traced through it and the problem is that char2wchar() is
completely brain-dead: at some places it thinks that "len" is the
length of the output wchar array, and at others it thinks that "len"
is the number of bytes in the input.  In particular, _t_isalpha()
fails completely for any multibyte character, because the pnstrdup
call truncates the character to 1 byte.

After looking at the callers I'm inclined to think that the only
safe way to implement this routine is to change its API to provide
both counts.  Comments?

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] BUG #3734: Invalid XML schema output.

2007-11-09 Thread Euler Taveira de Oliveira

Ben Leslie wrote:

> The specific problem is that the following is malformed; the xsd:restriction
> tag is never closed.
> 
>  
>
>  
> 
Exact. Per 9.11 (6, b, iv) or 9.15 (8, m, vi), it's a simple element.
The attached patch should fix it.
I'm attaching another small patch to strip some space and be consistent
with other xml tags.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
*** src/backend/utils/adt/xml.c.orig	2007-11-09 16:33:56.0 -0200
--- src/backend/utils/adt/xml.c	2007-11-09 16:37:30.0 -0200
***
*** 2987,2993 
  	base_typeoid = getBaseTypeAndTypmod(typeoid, &base_typmod);
  
  	appendStringInfo(&result,
! 	 "  \n",
  	 map_sql_type_to_xml_name(base_typeoid, base_typmod));
  }
  		}
--- 2987,2993 
  	base_typeoid = getBaseTypeAndTypmod(typeoid, &base_typmod);
  
  	appendStringInfo(&result,
! 	 "  \n",
  	 map_sql_type_to_xml_name(base_typeoid, base_typmod));
  }
  		}
*** src/backend/utils/adt/xml.c.orig	2007-11-09 16:33:56.0 -0200
--- src/backend/utils/adt/xml.c	2007-11-09 17:01:50.0 -0200
***
*** 2595,2605 
  
  		if (!tableforest)
  			appendStringInfo(&result,
! 			 "\n",
  			 xmltn, tabletypename);
  		else
  			appendStringInfo(&result,
! 			 "\n",
  			 xmltn, tabletypename);
  	}
  
--- 2595,2605 
  
  		if (!tableforest)
  			appendStringInfo(&result,
! 			 "\n",
  			 xmltn, tabletypename);
  		else
  			appendStringInfo(&result,
! 			 "\n",
  			 xmltn, tabletypename);
  	}
  
***
*** 2656,2662 
  		NULL);
  
  		appendStringInfo(&result,
! 		 "\n",
  		 xmlsn, schematypename);
  	}
  
--- 2656,2662 
  		NULL);
  
  		appendStringInfo(&result,
! 		 "\n",
  		 xmlsn, schematypename);
  	}

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [BUGS] BUG #3730: Creating a swedish dictionary fails

Magnus Hagander wrote:
> 
> On Fri, 2007-11-09 at 10:27 -0300, Alvaro Herrera wrote:
> > Penty Wenngren wrote:
> > 
> > > If you are confident that this is not a PostgreSQL bug, I'll accept that
> > > happily and move on to do some more testing on my end.
> > 
> > I don't think it has been shown that this is not our bug.  I reproduced
> > your problem here on an UTF8 environment and it does fail for me.
> > On the other hand, I am unsure how to test whether Ö is letter here, but
> > at least lower() works on it:
> 
> Not sure exactly what you mean, but Ö certainly is a letter, and ö is
> the lowercase of it, so that part looks correct.

Of course, the point is knowing whether the server believes that to be
the case :-)

-- 
Alvaro Herrera  Developer, http://www.PostgreSQL.org/
"Ellos andaban todos desnudos como su madre los parió, y también las mujeres,
aunque no vi más que una, harto moza, y todos los que yo vi eran todos
mancebos, que ninguno vi de edad de más de XXX años" (Cristóbal Colón)

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [BUGS] BUG #3730: Creating a swedish dictionary fails

Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I am wondering if the newline being included in the token could be
> > causing a problem.
> 
> Nope.  I traced through it and the problem is that char2wchar() is
> completely brain-dead: at some places it thinks that "len" is the
> length of the output wchar array, and at others it thinks that "len"
> is the number of bytes in the input.  In particular, _t_isalpha()
> fails completely for any multibyte character, because the pnstrdup
> call truncates the character to 1 byte.

Ah, that explains it.  I was reading that code too and did not
understand what was going on.

> After looking at the callers I'm inclined to think that the only
> safe way to implement this routine is to change its API to provide
> both counts.  Comments?

+1

-- 
Alvaro Herrera http://www.flickr.com/photos/alvherre/
Licensee shall have no right to use the Licensed Software
for productive or commercial use. (Licencia de StarOffice 6.0 beta)

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [BUGS] Postgresql Domain Names

2007-11-09 Thread Linda O


Dave- we received a similar solicitation at Artemis Woman

Did these people turn out to be legitimate?

Thanks 
Linda O



People; please *do not* respond to this. Someone from -core will handle it.

Thanks, Dave

-- 
Dave Page
PostgreSQL Core Team


-- 
View this message in context: 
http://www.nabble.com/Postgresql-Domain-Names-tf4736701.html#a13673726
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [BUGS] Postgresql Domain Names

2007-11-09 Thread Dave Page

Linda O wrote:
> Dave- we received a similar solicitation at Artemis Woman
> 
> Did these people turn out to be legitimate?

Linda,

As far as I know they haven't asked any of us for any personal info,
money, bank details or anything like that. It appears to have been a
legitimate query. That said, you should still be cautious and make sure
you don't hand over any info that might be used inappropriately.

Regards, Dave.

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] Postgresql Domain Names

2007-11-09 Thread Andrew Sullivan

On Fri, Nov 09, 2007 at 07:59:07PM +, Dave Page wrote:
> 
> As far as I know they haven't asked any of us for any personal info,
> money, bank details or anything like that. It appears to have been a
> legitimate query. That said, you should still be cautious and make sure
> you don't hand over any info that might be used inappropriately.

Please be extra careful.  They don't appear to be a CNNICaccredited
registrar.

Also, note that .mobi isn't a Chinese domain name (I know this because
Afilias provides technical operations for mTLD).  They may, however, be
trolling for registrants for the "Chinese" version of .mobi, which China
appears to be pressing ahead with in a split root that they're running.

A

-- 
Andrew Sullivan
Old sigs will return after re-constitution of blue smoke

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

[BUGS] BUG #3739: server process (PID XXX) exited with exit code -1073741502

2007-11-09 Thread Jose


The following bug has been logged online:

Bug reference:  3739
Logged by:  Jose
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system:   Windows XP Pro SP2
Description:server process (PID XXX) exited with exit code
-1073741502
Details: 

Process terminating abnormally many times.

server process (PID XXX) exited with exit code -1073741502

2007-11-06 14:50:12 WARNING:  terminating connection because of crash of
another server process

2007-11-06 14:50:12 DETAIL:  The postmaster has commanded this server
process to roll back the current transaction and exit, because another
server process exited abnormally and possibly corrupted shared memory.

2007-11-06 14:50:12 HINT:  In a moment you should be able to reconnect to
the database and repeat your command.

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [BUGS] BUG #3730: Creating a swedish dictionary fails