Re: [GENERAL] Reusing cached prepared statement slow after 5 executions
I can confirm, when I call ps.setPrepareThreshold(1) the query is slow immediately, so the plan must be different with the server prepared statements. Thanks, Rob On Sun, Jun 26, 2011 at 5:11 PM, Tom Lane t...@sss.pgh.pa.us wrote: David Johnston pol...@yahoo.com writes: This is likely the case where the first few prepared statements are not truly prepared. Once you hit five the cache kicks in and computes a generic query plan to cache. Not so much that as that JDBC decides that it should tell the backend to start using a prepared plan. See the JDBC docs. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Anyone using silent_mode?
Is anyone using silent_mode=on ? There's some discussion on pgsql-hackers [1] on whether it should be removed altogether in 9.2, since you can get the same functionality with pg_ctl start, or nohup. If you're using silent_mode, what are you using it for? [1] http://archives.postgresql.org/message-id/1308926157-sup-7...@alvh.no-ip.org -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] An amusing MySQL weakness--not!
Στις Sunday 26 June 2011 17:11:06 ο/η Vincent Veyron έγραψε: Le dimanche 26 juin 2011 � 00:05 -0700, Darren Duncan a �crit : Michael Nolan wrote: Having real BOOLEAN is just one of the reasons I like Postgres the most. Would you mind giving an example of where a boolean field would be a win over an integer one? I'm asking this because I frequently wonder what is best for my use; I normally query postgres via Perl modules, which don't care about boolean (the driver converts t/f to 0/1), but I like to tune my fields properly. Alright, but in other enterprise-level platforms, like java, there is a boolean data type and a Boolean class wrapper. -- Vincent Veyron http://marica.fr/ Logiciel de gestion des sinistres et des contentieux pour le service juridique -- Achilleas Mantzios -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Anyone using silent_mode?
On Mon, 2011-06-27 at 10:06 +0300, Heikki Linnakangas wrote: Is anyone using silent_mode=on ? There's some discussion on pgsql-hackers [1] on whether it should be removed altogether in 9.2, since you can get the same functionality with pg_ctl start, or nohup. If you're using silent_mode, what are you using it for? [1] http://archives.postgresql.org/message-id/1308926157-sup-7...@alvh.no-ip.org Not using it. Never did, and won't. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Reusing cached prepared statement slow after 5 executions
On 27 June 2011 07:50, Rob Gansevles rgansev...@gmail.com wrote: I can confirm, when I call ps.setPrepareThreshold(1) the query is slow immediately, so the plan must be different with the server prepared statements. You can confirm that from psql by doing EXPLAIN ANALYSE SELECT ... ; and then PREPARE ps( ... ) AS SELECT ... ; EXPLAIN ANALYSE EXECUTE ps ( ... ) ; using your query and the parameters in question. It is entirely possible that the plan chosen for the prepared statement will be worse than the one used when the parameters are known at planning time. The prepared statement doesn't know what parameters are going to be used, so it can't always come up with the best plan. See the notes in the PREPARE manual page: http://www.postgresql.org/docs/9.0/static/sql-prepare.html Regards, Dean -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Custom types as parameter in stored function
Ehmmm, sorry.. Correct syntax for select is: select myfunc((1, 'foo')::myType); -- View this message in context: http://postgresql.1045698.n5.nabble.com/Custom-types-as-parameter-in-stored-function-tp4527618p4527663.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Custom types as parameter in stored function
Hello to everyone, I am trying to pass custom types as parameters in stored functions, and I tried this syntax successfully: create type myType as (id bigint, name character varying); create or replace myfunc(obj myType) returns void as begin ... end; select myfunc((1, 'foo')::myType; In this manner, if I understand it, there is a positional assignment of attribute value: id = 1 and name = foo. My ask is is there a manner to assing value to attribute of custom type by name instead by position. Thanks in advance. Mephysto. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Custom-types-as-parameter-in-stored-function-tp4527618p4527618.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] An amusing MySQL weakness--not!
On Sunday 26. June 2011 16.11.06 Vincent Veyron wrote: Le dimanche 26 juin 2011 à 00:05 -0700, Darren Duncan a écrit : Michael Nolan wrote: Having real BOOLEAN is just one of the reasons I like Postgres the most. Would you mind giving an example of where a boolean field would be a win over an integer one? I'm asking this because I frequently wonder what is best for my use; I normally query postgres via Perl modules, which don't care about boolean (the driver converts t/f to 0/1), but I like to tune my fields properly. PHP has its own Boolean values TRUE/FALSE, but reads Postgresql Booleans as 't'/'f'. You always have to rely on kludgy konstructs like if ($pg_bool == 't') then $my_bool = TRUE; elseif ($pg_bool == 'f') then $my_bool = FALSE; else $my_bool = NULL; It's of course much easier to use integer values, but it sucks not to use a bool when you want a variable that can't be anything but TRUE, FALSE or NULL. It obfuscates the code to use a var that evaluates to an integer, but in reality is a Boolean in disguise. regards, Leif -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Reusing cached prepared statement slow after 5 executions
Dean Rasheed wrote: I can confirm, when I call ps.setPrepareThreshold(1) the query is slow immediately, so the plan must be different with the server prepared statements. You can confirm that from psql by doing EXPLAIN ANALYSE SELECT ... ; and then PREPARE ps( ... ) AS SELECT ... ; EXPLAIN ANALYSE EXECUTE ps ( ... ) ; using your query and the parameters in question. It is entirely possible that the plan chosen for the prepared statement will be worse than the one used when the parameters are known at planning time. The prepared statement doesn't know what parameters are going to be used, so it can't always come up with the best plan. See the notes in the PREPARE manual page: http://www.postgresql.org/docs/9.0/static/sql-prepare.html Could the parameter cursor_tuple_fraction play a role here too? Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] discard on constraint violation
Is there a way to tell a table to discard an insert if it violates a
constraint (unique in my case) instead of giving an error? I don't want
the overhead of a trigger on each row inserted.
My situation is that I'm reading data from an external website with lots
of duplicate data. I am reading the data in a plpythonu function. I
never update, only insert. A trigger on the table that has to check if
each row exists before trying the insert is too much overhead.
I tried in plpython:
create or replace function testme() returns bool as
$$
try:
plpy.execute(insert into
reports.survey_types(typeid,name)values(1,'test'))
return true
except:
plpy.notice('the constraint was violated')
return false
$$language 'plpythonu';
where the insert violates a unique constraint and it never gets to the
except. The function dies and doesn't get to my except with:
WARNING: plpython: in function testme:
DETAIL: class 'plpy.SPIError': Unknown error in PLy_spi_execute_query
ERROR: duplicate key violates unique constraint survey_types_pkey
CONTEXT: SQL statement insert into
reports.survey_types(typeid,name)values(1,'test')
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] An amusing MySQL weakness--not!
Le lundi 27 juin 2011 à 12:11 +0200, Leif Biberg Kristensen a écrit : PHP has its own Boolean values TRUE/FALSE, but reads Postgresql Booleans as 't'/'f'. You always have to rely on kludgy konstructs like if ($pg_bool == 't') then $my_bool = TRUE; elseif ($pg_bool == 'f') then $my_bool = FALSE; else $my_bool = NULL; It's of course much easier to use integer values, but it sucks not to use a bool when you want a variable that can't be anything but TRUE, FALSE or NULL. Same thing with Perl. But I am starting to think that the benefits of data integrity mentionned by Stephen are worth the extra effort : you save on validation needs anyway, which is probably another couple of lines, if not more, and less reliable. -- Vincent Veyron http://marica.fr/ Logiciel de gestion des sinistres et des contentieux pour le service juridique -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] discard on constraint violation
On Mon, 2011-06-27 at 15:36 +0300, Sim Zacks wrote: Is there a way to tell a table to discard an insert if it violates a constraint (unique in my case) instead of giving an error? I don't want the overhead of a trigger on each row inserted. Without a trigger, you can't. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Reusing cached prepared statement slow after 5 executions
This behavior is in some way needed, as PreparedStatement is, commonly, used once, just to pass parameters without escaping. Regards, Radek -Original Message- From: Rob Gansevles Sent: 27 czerwca 2011 08:50 To: pgsql-general Subject: Re: [GENERAL] Reusing cached prepared statement slow after 5 executions I can confirm, when I call ps.setPrepareThreshold(1) the query is slow immediately, so the plan must be different with the server prepared statements. Thanks, Rob On Sun, Jun 26, 2011 at 5:11 PM, Tom Lane t...@sss.pgh.pa.us wrote: David Johnston pol...@yahoo.com writes: This is likely the case where the first few prepared statements are not truly prepared. Once you hit five the cache kicks in and computes a generic query plan to cache. Not so much that as that JDBC decides that it should tell the backend to start using a prepared plan. See the JDBC docs. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] discard on constraint violation
My situation is that I'm reading data from an external website with lots of duplicate data. I am reading the data in a plpythonu function. I never update, only insert. A trigger on the table that has to check if each row exists before trying the insert is too much overhead. Create a staging table into which you import your external data and then write a query of the form INSERT INTO realtable SELECT FROM stagingtable WHERE stagingtable NOT EXISTS realtable. David J. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] to_timestamp() and timestamp without time zone
From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of hernan gonzalez Sent: Sunday, June 26, 2011 3:57 PM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] to_timestamp() and timestamp without time zone An analogy: a localtime is like a relative path in a filesystem. A full datetime spefication (date, time, timezone) would correspond to a absolute path. So let us call it Relative Time instead of Abstract/Local Time. I like this better since the term relative begs the question: relative to what which then needs to be answered (by adding a TimeZone) to possibly represent an Instant (or absolute time). However there is no guarantee that the process of turning the relative path into an absolute path will succeed just as there is no guarantee that a relative time exists when associated with a specific TimeZone. First: I would suggest your use of Local Time is incorrect and that you would be better off thinking of it as Abstract Time. My responses below go into more detail but in short you obtain a Local time by Localizing and Abstract time. The process of Localization requires a relevant Locale input which, for date/time values, is a TimeZone. That's not the way in which the expression Local (date) time is normally used, rather the opossite. A localtime is normally a time which is to be understood relatively to some unespecified timezone. Precisely, when we (in common usage) specify a datetime, we say a date, a time and then either add some specific timezone OR do not state it : just say localtime. That is, we either say The event happened 2011-10-03 12:00:00 , Eastern Time OR we say The event happened 2011-10-03 12:00:00 (localtime) International offices will close the first semester at 2011-06-31 23:59:00 (localtime) In all the above examples the use of the localtime simply means in the timezone in which the event physically happened or in which the post offices are physically located. It is exactly in this sense that I suggest LocalTime be used. The TimeZone itself may or may not be known but it is implied and present none-the-less. This make sense because any time specification of a physical event can and is specified by an instant. In fact, in pretty all common usage we are dealing with Instances and not Relative Time. This is because we are dealing with the past and thus the location is already known. It is when the location is unknown, in the future or if there could be multiple, that you supply the Abstract Time to the user and let them figure out at what Instant they should do something. So, saying go to bed at 2AM local time means bed time is 2AM no matter where you are; when you arrive someplace attach your current TimeZone to the 2AM Abstract Time and go to bed at that Instant. That's also how the word is used in APIs (see Joda time) The Joda-Time API indeed defines its LocalTime is the same manner as I've suggested defining Relative Time; I would argue that their use of LocalTime is also mis-guided for the reasons already stated. Saying that someone else does something is generally a poor defense for a position. Group-think is useful but, as in this case, your supporting group is fallible; they made the same mistake as you (or rather your parroting of their position reflected their mistake as well). It is a subtle and inconsequential mistake since most people would make the same one and the actual definitions and implementations are consistent and serve the needed purpose. In the same way timestamp and timestamptz have their own mistakes surrounding them (due to the re-characterization during the version 7.x timeline) but they are consistently defined and implemented and provide the same two models that Joda-Time does - just under different labels. One sensible paraphrase of LocalTime - to include the prefix local - is A time value that needs to be localized in order to possibly represent an instant. This works but for this, as for other things generally, I first determine what it is I need to represent and then I scan the documentation for Names that seems to do similar things. I then read the description so see whether I have found the correct one. Naming perfection is not required; as long as the label is close in meaning I'll generally find what is needed if it is there. Then I just associate that API/label with the behavior/feature I need and use it simply as-is - without an in-depth analysis of whether it is fully logical since - in programming - it is difficult to fix public mistakes. David J.
[GENERAL] Live records and number of records are differents...
Hello list, I use PostgreSQL 8.4 and Postgis 1.4. I use FME to insert 772185 records in a table (multipolygons that represent parcels). Everything seems fine but... If I type select count(*), I get the right number of records : 772185 records. But If I use pgAdmin and have a look in the stats : - row inserted = 772185 OK fine, - but the number of live rows is 772308... I don't understand why the number of live rows and the number of rows is différent... Any explaination would be very appreciated ! Thanks you Fabrice attachment: pb1.png -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Live records and number of records are differents...
On Mon, Jun 27, 2011 at 4:12 PM, F T ouk...@gmail.com wrote: Hello list, I use PostgreSQL 8.4 and Postgis 1.4. I use FME to insert 772185 records in a table (multipolygons that represent parcels). Everything seems fine but... If I type select count(*), I get the right number of records : 772185 records. But If I use pgAdmin and have a look in the stats : - row inserted = 772185 OK fine, - but the number of live rows is 772308... I don't understand why the number of live rows and the number of rows is différent... Any explaination would be very appreciated ! Thanks you PgAdmin uses the statistical information , that's updated by (auto)vacuum and not running the actual select count(*) I believe. -- GJ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Custom types as parameter in stored function
On Mon, Jun 27, 2011 at 4:33 AM, mephysto genna...@email.it wrote: Hello to everyone, I am trying to pass custom types as parameters in stored functions, and I tried this syntax successfully: create type myType as (id bigint, name character varying); create or replace myfunc(obj myType) returns void as begin ... end; select myfunc((1, 'foo')::myType; In this manner, if I understand it, there is a positional assignment of attribute value: id = 1 and name = foo. My ask is is there a manner to assing value to attribute of custom type by name instead by position. You can do it via hstore in 9.0+...just be aware it is slower than the row constructor method. See the example below -- note CREATE EXTENSION is a 9.1 feature -- to do it in 9.0 you have to install the contrib script manually. postgres=# create extension hstore; WARNING: = is deprecated as an operator name DETAIL: This name may be disallowed altogether in future versions of PostgreSQL. CREATE EXTENSION postgres=# create type t as (a int, b text); CREATE TYPE postgres=# select populate_record(null::t, 'b=9, a=2'); populate_record - (2,9) merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] In a view, how do I cause fields with possible NULLs to be treated as a blank string in a replace operation?
Hello, So I have am playing with a view to test the feasibility of a technique for storing some data. It basically goes something like this: CREATE VIEW formatted_table AS SELECT name, replace(some_template, '@', some_type) AS some_field FROM some_table; some_template is something like 'foo@bar' or 'foobar' (note the missing template character). some_type is a single letter like 'a' or 'b', or it can be NULL. The above view works fine for rows where some_type is a letter, and some_field ends up as 'fooabar' or whatever. However, when some_type is NULL, some_field ends up as NULL as well. I understand that this is expected behaviour, but how do I cause the view to treat a some_type of NULL as an empty string, so that some_field simply ends up as 'foobar'? Hope that was clear. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] In a view, how do I cause fields with possible NULLs to be treated as a blank string in a replace operation?
On 27 June 2011 17:53, Asfand Qazi (Sanger Institute) aq2.san...@gmail.com wrote: Hello, So I have am playing with a view to test the feasibility of a technique for storing some data. It basically goes something like this: CREATE VIEW formatted_table AS SELECT name, replace(some_template, '@', some_type) AS some_field FROM some_table; some_template is something like 'foo@bar' or 'foobar' (note the missing template character). some_type is a single letter like 'a' or 'b', or it can be NULL. The above view works fine for rows where some_type is a letter, and some_field ends up as 'fooabar' or whatever. However, when some_type is NULL, some_field ends up as NULL as well. I understand that this is expected behaviour, but how do I cause the view to treat a some_type of NULL as an empty string, so that some_field simply ends up as 'foobar'? Hope that was clear. Try coalesce: http://www.postgresql.org/docs/9.0/static/functions-conditional.html#AEN15541 So if foo is a null value, and you used COALESCE(foo, 'bar'), the output would be 'bar', otherwise it would be whatever the value of foo is. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] In a view, how do I cause fields with possible NULLs to be treated as a blank string in a replace operation?
Either use '' as some_type, or use COALESCE(some_type, ''). On Mon, Jun 27, 2011 at 9:53 AM, Asfand Qazi (Sanger Institute) aq2.san...@gmail.com wrote: Hello, So I have am playing with a view to test the feasibility of a technique for storing some data. It basically goes something like this: CREATE VIEW formatted_table AS SELECT name, replace(some_template, '@', some_type) AS some_field FROM some_table; some_template is something like 'foo@bar' or 'foobar' (note the missing template character). some_type is a single letter like 'a' or 'b', or it can be NULL. The above view works fine for rows where some_type is a letter, and some_field ends up as 'fooabar' or whatever. However, when some_type is NULL, some_field ends up as NULL as well. I understand that this is expected behaviour, but how do I cause the view to treat a some_type of NULL as an empty string, so that some_field simply ends up as 'foobar'? Hope that was clear. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Rick Genter rick.gen...@gmail.com
Re: [GENERAL] glitch installing xml support in 9.1.beta2
On 06/25/2011 01:10 AM, Guillaume Lelarge wrote: On Fri, 2011-06-24 at 11:22 -0600, Rob Sargent wrote: OpenSuse 11.4 x86-64 gmake install builds and places the requisite pieces as expected. Running psql --username postgres -d postgres -f xml2--1.0,sql results in psql:xml2--1.0.sql:8: ERROR: function xml_valid already exists with same argument types psql:xml2--1.0.sql:12: ERROR: could not access file MODULE_PATHNAME: No such file or directory psql:xml2--1.0.sql:16: ERROR: could not access file MODULE_PATHNAME: No such file or directory psql:xml2--1.0.sql:20: ERROR: could not access file MODULE_PATHNAME: No such file or directory psql:xml2--1.0.sql:24: ERROR: could not access file MODULE_PATHNAME: No such file or directory psql:xml2--1.0.sql:28: ERROR: could not access file MODULE_PATHNAME: No such file or directory psql:xml2--1.0.sql:34: ERROR: could not access file MODULE_PATHNAME: No such file or directory (This from second run, so xml_valid worked the first time). I see that the xml2.control file defines module_pathname = '$libdir/pgxml', but how is that passed to the psql run? Or am I to manually update the sql scripts? . You don't use it explicitely. You use CREATE EXTENSION, and it will use it. psql --username postgres -d postgres -c CREATE EXTENSION xml2 and it should work. That's one of the great things in 9.1. Worked perfectly for xml2 thanks. As for uuid I had to run the extendor like this: psql --username=postgres -d postgres -c 'create extension uuid-ossp' Unfortunate hyphenation in the name of the module. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Custom types as parameter in stored function
Thank you Merlin. Now, Can I pass the select as an argument of my function? Or must I do in other manner? Sorry, but I am a novice. Best regards. Mephysto -- View this message in context: http://postgresql.1045698.n5.nabble.com/Custom-types-as-parameter-in-stored-function-tp4527618p4529531.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Custom types as parameter in stored function
On Mon, Jun 27, 2011 at 2:22 PM, mephysto genna...@email.it wrote: Thank you Merlin. Now, Can I pass the select as an argument of my function? sure: select myfunc(populate_record(null::t, 'b=9, a=2')); merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Live records and number of records are differents...
On 06/27/2011 11:12 PM, F T wrote: - but the number of live rows is 772308... The UI should really say something like Stats: Estimated number of live rows: 772308 to indicate more clearly what's going on. At least putting it under a Statistics and Estimates heading/category would help. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Gist Index: Problem getting data in GiST Support Functions penalty.
I am running 9.0.4 and I'm running it on Windows 7 Ultimate which is my development machine. I can't even create a server. When I try I get a message 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 192.168.1.150 and accepting TCP/IP connections on port 5432? PostGres has been given access through the firewall on port 5432. My pg_hba.config file has the following line # TYPE DATABASEUSERCIDR-ADDRESSMETHOD # IPv4 local connections: hostall all 0.0.0.0/0 trust I am just trying to get logged in at this point so I'm basically not trying to use any security. This is becoming a huge problem for me. I need to have the schema imported into the database by Thursday of this week when we are supposed to show off a new module in our product. We've not had any problems in other customer locations trying to get in. Any ideas? Best Regards Michael Gould -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
