date:20130224

Re: [GENERAL] autoanalyze criteria

2013-02-24 Thread Alban Hertroys

On Feb 23, 2013, at 14:11, Stefan Andreatta  wrote:

> And we are still missing a number for rows updated since the last analyse.

In MVCC an update is an insert + delete, so you already got those numbers.

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.

Re: [GENERAL] Dumb question involving to_tsvector and a view

2013-02-24 Thread Kevin Grittner

Jasen Betts  wrote:
>On 2013-02-23, Raymond C. Rodgers  wrote:

>> On 02/23/2013 05:26 AM, Tom Lane wrote:
>>> A "virtual" tsvector like that is probably going to be useless for
>>> searching as soon as you get a meaningful amount of data, because the
>>> only way the DB can implement a search is to compute the tsvector
>>> value for each table row and then examine it for the target word(s).
>>> What you want is a GIST or GIN index on the contents of the tsvector.
>
>> I think the only real advantage to using something like this would be a
>> space savings in terms of storing the tsvector data, but I don't see
>> that being a significant enough reason to go ahead and use this idea in
>> a production situation. As mentioned [by pretty much all of us], once
>> the table size is sufficiently large there would be a performance
>> penalty by to_tsvector being executed on every record in the table.
>
>Unless the plan comes out as a table scan the index will be used
>instead ot to_tsvector()
>
>When there is a table scan to_tsvector will be used instead of reading
>from disk, I don't know how fast to_tsvector is compared to disk, but
>usually computing a result is faster than reading it from disk.
>
>Storing the tsvector in the table is likely to be faster only when a
>tablescan is done and the table is fully cached in ram.

I guess I was being dumb in assuming that it was obvious that a GIN
or GiST index would be needed for decent performance at scale. 
Without that, a scan of the whole table (or at least all rows
matching other search criteria) is needed, which is going to hurt. 
The benchmarks I mentioned were for a GIN index on the results of
the function which generated the tsvector, versus a GIN index on
the stored tsvector.  In our case, a typical scan for document text
against years of accumulated court documents was about 300 ms
versus about 1.5 seconds.  It may matter that we weren't just
looking for matches, but the top K matches based on the ranking
function.

-- 
Kevin Grittner
EnterpriseDB: 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] [JDBC] can't access through SSL

2013-02-24 Thread Ray Stell

On Feb 23, 2013, at 11:05 PM, Maz Mohammadi wrote:
>  
> FATAL:  connection requires a valid client certificate. 

I use openssl to verify the chain, I think that would help you know what's 
going on:

openssl verify -CAfile rootca.crt  user.crt

Re: [GENERAL] [JDBC] can't access through SSL

2013-02-24 Thread Adrian Klaver


On 02/23/2013 08:05 PM, Maz Mohammadi wrote:

I still can’t access my SSL enabled server!!!

Is root.crt supposed to be an exact copy of server.crt file which I use
in my client’s keystore?

I have another observation.  As I start the coordinator node, I don’t
see any file access to the server.key or server.crt file?  Aren’t these
files supposed to be read at start up time or at least when I try to
make a connection from my java application?

Everything I try create a datasource on tomcat I get the follow error on
client and server’s console…

FATAL:  connection requires a valid client certificate.

Am I missing something?


It would seem that from this thread you are working with Postgres-XC not 
Postgres, is that correct?




-maz




--
Adrian Klaver
adrian.kla...@gmail.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] [JDBC] can't access through SSL

2013-02-24 Thread Maz Mohammadi

Correct!

I'm new postgresql and I need to figure this out for a client.  I installed a 
bunch packages on my Ubuntu linux and here I am.  I've learned a lot.  I have 2 
datanodes, coordinator + gtm.  

-maz

-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@gmail.com] 
Sent: Sunday, February 24, 2013 4:37 PM
To: Maz Mohammadi
Cc: pgsql-j...@postgresql.org; pgsql-general@postgresql.org
Subject: Re: [GENERAL] [JDBC] can't access through SSL

On 02/23/2013 08:05 PM, Maz Mohammadi wrote:
> I still can't access my SSL enabled server!!!
>
> Is root.crt supposed to be an exact copy of server.crt file which I 
> use in my client's keystore?
>
> I have another observation.  As I start the coordinator node, I don't 
> see any file access to the server.key or server.crt file?  Aren't 
> these files supposed to be read at start up time or at least when I 
> try to make a connection from my java application?
>
> Everything I try create a datasource on tomcat I get the follow error 
> on client and server's console...
>
> FATAL:  connection requires a valid client certificate.
>
> Am I missing something?

It would seem that from this thread you are working with Postgres-XC not 
Postgres, is that correct?

>
> -maz
>
>

--
Adrian Klaver
adrian.kla...@gmail.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] [JDBC] can't access through SSL

2013-02-24 Thread Adrian Klaver


On 02/24/2013 02:35 PM, Maz Mohammadi wrote:

Correct!

I'm new postgresql and I need to figure this out for a client.  I installed a 
bunch packages on my Ubuntu linux and here I am.  I've learned a lot.  I have 2 
datanodes, coordinator + gtm.


Some general pointers on helping to figure this out:

1) Postgres-XC != Postgres. It shares a code base but adds more moving 
parts. Along that line, you will need to be more specific about how you 
have setup Postgres-XC and exactly which part is failing? I for one do 
not use it, so I am not really sure what datanodes, coordinator and gmt 
signify. On a related note XC has its own mailing 
list(https://lists.sourceforge.net/lists/listinfo/postgres-xc-general), 
it may turn out there are people there that can answer the question sooner.



2) JDBC. It would seem from this thread and the other that covered this 
topic that JDBC is not really the issue. To make your life simpler I 
would test your setup using psql until you get it running properly, then 
pull in JDBC to see if it adds any problems. Also, it is generally 
considered not good protocol to cross post the same issue to different 
lists.



3) Simple with more detail is better. Create a minimum use case and then 
provide maximum detail of how it was set up and run. For instance:


a) What are the versions of the software?
b) Where is the client being run from?
c) Where is the server?
d) How are both setup?
e) What is being done between the client and the server?
f) What do you expect to happen?
g) What is actually happening?
i) The actual error message(s)?



-maz




--
Adrian Klaver
adrian.kla...@gmail.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] [JDBC] can't access through SSL

2013-02-24 Thread Maz Mohammadi

Hi Adrian,

Thanks for sharing some pointers with me.  You are right, it's not actually an 
JDBC driver issue.  I posted it on jdbc, because I'm accessing it from a jdbc 
client, I thought there might be some security issues with the JDBC driver.

1) I'm running postgres-xc v. 9.1.  I'm "pretty" sure that my postgres setup is 
correct.  Another person from this distribution list help me a bit.  This test 
shows me that the ssl is setup correctly on my server...

--
postgres-xc@adminuser-VirtualBox:~/datanode2$ psql 
psql (PGXC 1.0.0, based on PG 9.1.4)
Type "help" for help.

postgres=# \q
postgres-xc@adminuser-VirtualBox:~/datanode2$ psql -h localhost
psql: FATAL:  connection requires a valid client certificate
FATAL:  no pg_hba.conf entry for host "127.0.0.1", user "postgres-xc", database 
"postgres", SSL off
postgres-xc@adminuser-VirtualBox:~/datanode2$

2) My client is a tomcat server.  I've placed JDBC3 drivers (jar file) in the 
WEB-INF lib directory of my webapp. 

3) MY jdbc url is "jdbc:postgresql://localhost:5432:testdb?ssl=true", and 
believe me username and password are correct.

4) Both postgres and tomcat are running on the same machine (an Ubuntu linux 
virtual box).  

5) when I try to create a JDBC datasource on my tomcat, I enter the JDBC url + 
user + password, and I'm expecting it to be able to connect to it and at least 
get a "test successful" but I don't.  I get the error that I sent...
"Connection attempt failed: FATAL: connection requires a valid client 
certificate"

6) I've also specified the following java options..
-Djavax.net.ssl.trustStore=/home/adminuser/pentaho/keycerts/mazstore 
-Djavax.net.ssl.trustStorePassword=password

I'll post this on the other distribution list.  BTW, I don't see much in the 
log files under /var/log directory.

-maz

-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@gmail.com] 
Sent: Sunday, February 24, 2013 8:08 PM
To: Maz Mohammadi
Cc: pgsql-j...@postgresql.org; pgsql-general@postgresql.org
Subject: Re: [GENERAL] [JDBC] can't access through SSL

On 02/24/2013 02:35 PM, Maz Mohammadi wrote:
> Correct!
>
> I'm new postgresql and I need to figure this out for a client.  I installed a 
> bunch packages on my Ubuntu linux and here I am.  I've learned a lot.  I have 
> 2 datanodes, coordinator + gtm.

Some general pointers on helping to figure this out:

1) Postgres-XC != Postgres. It shares a code base but adds more moving parts. 
Along that line, you will need to be more specific about how you have setup 
Postgres-XC and exactly which part is failing? I for one do not use it, so I am 
not really sure what datanodes, coordinator and gmt signify. On a related note 
XC has its own mailing 
list(https://lists.sourceforge.net/lists/listinfo/postgres-xc-general),
it may turn out there are people there that can answer the question sooner.

2) JDBC. It would seem from this thread and the other that covered this topic 
that JDBC is not really the issue. To make your life simpler I would test your 
setup using psql until you get it running properly, then pull in JDBC to see if 
it adds any problems. Also, it is generally considered not good protocol to 
cross post the same issue to different lists.

3) Simple with more detail is better. Create a minimum use case and then 
provide maximum detail of how it was set up and run. For instance:

a) What are the versions of the software?
b) Where is the client being run from?
c) Where is the server?
d) How are both setup?
e) What is being done between the client and the server?
f) What do you expect to happen?
g) What is actually happening?
i) The actual error message(s)?

>
> -maz
>

--
Adrian Klaver
adrian.kla...@gmail.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] Floating point error

2013-02-24 Thread Tom Duffey

Hi Everyone,

Riddle me this. I have a database column of type "real" that gets mapped to a 
Java field of type double via JDBC. We have two databases, test and production, 
and the test database is periodically blown away and reloaded from a copy of 
production. We recently noticed that some values do not match when viewed 
within our application on test vs. production. More specifically:

- Selecting values from both test and production DBs using psql shows "10.3885" 
as the value
- The Java app on production shows "10.3884573" while the test app shows 
"10.3885"

I have a hunch that when the value was originally inserted into the production 
DB it probably contained more than the 6 digits supported by the real data 
type. It may have even been exactly the "10.3884573" value we see when 
retrieving via JDBC on production. What I don't understand is why when the 
value gets mapped back to Java via JDBC those extra digits are coming back. Can 
anyone explain this or do you think I'm on the wrong track? I stepped through 
code and it sure seems like the extra information is coming back from the JDBC 
driver.

Tom

--
Tom Duffey
tduf...@trillitech.com
414-751-0600 x102



-- 
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] Floating point error

2013-02-24 Thread John R Pierce


On 2/24/2013 6:13 PM, Tom Duffey wrote:

- The Java app on production shows "10.3884573" while the test app shows 
"10.3885"


'real' is single precision, which is only about 6 digits of decimal 
accuracy.   if your java variables were double precision, you probably 
should have used double in postgres too.


0.1 decimal is a repeating fraction in binary.



--
john r pierce  37N 122W
somewhere on the middle of the left coast



--
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] Floating point error

2013-02-24 Thread John R Pierce


On 2/24/2013 6:20 PM, John R Pierce wrote:

On 2/24/2013 6:13 PM, Tom Duffey wrote:
- The Java app on production shows "10.3884573" while the test app 
shows "10.3885"


'real' is single precision, which is only about 6 digits of decimal 
accuracy.   if your java variables were double precision, you probably 
should have used double in postgres too.


0.1 decimal is a repeating fraction in binary. 


ooops, missed my third point.if precise decimal numbers are 
important, use a decimal data type, which is NUMERIC in SQL (I'm not 
familiar enough with Java to know if it has a BCD or other decimal type).


--
john r pierce  37N 122W
somewhere on the middle of the left coast



--
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] Floating point error

2013-02-24 Thread Edson Richter


Em 24/02/2013 23:26, John R Pierce escreveu:

On 2/24/2013 6:20 PM, John R Pierce wrote:

On 2/24/2013 6:13 PM, Tom Duffey wrote:
- The Java app on production shows "10.3884573" while the test app 
shows "10.3885"


'real' is single precision, which is only about 6 digits of decimal 
accuracy.   if your java variables were double precision, you 
probably should have used double in postgres too.


0.1 decimal is a repeating fraction in binary. 


ooops, missed my third point.if precise decimal numbers are 
important, use a decimal data type, which is NUMERIC in SQL (I'm not 
familiar enough with Java to know if it has a BCD or other decimal type).



Java BigDecimal is the best fit for Numeric in PostgreSQL

It requires a bit more programming effort, but is the most precise type 
for money work.


For instance to sum 2.00 plus 2.00 program:

public static void main(String [] args) {
BigDecimal num1 = new BigDecimal("2.00");
BigDecimal num2 = new BigDecimal("2.00");
BigDecimal sum = num1.add(num2);

if(sum.compareTo(new BigDecimal("4.00"))==0) {
  System.out.println("Matches: 2.00+2.00 == 4.00");
} else {
  System.out.println("Uau, how did you get here?");
}
}

You must use "compareTo" method to compare two values, and can't use 
BigDecimal "equals" to compare values, because 2.0 is different than 
2.00 (scale differ)...



Regards,

Edson


--
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] Floating point error

2013-02-24 Thread Adrian Klaver


On 02/24/2013 06:13 PM, Tom Duffey wrote:

Hi Everyone,

Riddle me this. I have a database column of type "real" that gets mapped to a 
Java field of type double via JDBC. We have two databases, test and production, and the 
test database is periodically blown away and reloaded from a copy of production. We 
recently noticed that some values do not match when viewed within our application on test 
vs. production. More specifically:

- Selecting values from both test and production DBs using psql shows "10.3885" 
as the value
- The Java app on production shows "10.3884573" while the test app shows 
"10.3885"

I have a hunch that when the value was originally inserted into the production DB it 
probably contained more than the 6 digits supported by the real data type. It may have 
even been exactly the "10.3884573" value we see when retrieving via JDBC on 
production. What I don't understand is why when the value gets mapped back to Java via 
JDBC those extra digits are coming back. Can anyone explain this or do you think I'm on 
the wrong track? I stepped through code and it sure seems like the extra information is 
coming back from the JDBC driver.


Are the production and test apps running on the same platform i.e. OS, 
bitness, etc.




Tom

--
Tom Duffey
tduf...@trillitech.com
414-751-0600 x102






--
Adrian Klaver
adrian.kla...@gmail.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] Floating point error

2013-02-24 Thread Tom Duffey

On Feb 24, 2013, at 8:44 PM, Adrian Klaver  wrote:

> On 02/24/2013 06:13 PM, Tom Duffey wrote:
>> Hi Everyone,
>> 
>> Riddle me this. I have a database column of type "real" that gets mapped to 
>> a Java field of type double via JDBC. We have two databases, test and 
>> production, and the test database is periodically blown away and reloaded 
>> from a copy of production. We recently noticed that some values do not match 
>> when viewed within our application on test vs. production. More specifically:
>> 
>> - Selecting values from both test and production DBs using psql shows 
>> "10.3885" as the value
>> - The Java app on production shows "10.3884573" while the test app shows 
>> "10.3885"
>> 
>> I have a hunch that when the value was originally inserted into the 
>> production DB it probably contained more than the 6 digits supported by the 
>> real data type. It may have even been exactly the "10.3884573" value we see 
>> when retrieving via JDBC on production. What I don't understand is why when 
>> the value gets mapped back to Java via JDBC those extra digits are coming 
>> back. Can anyone explain this or do you think I'm on the wrong track? I 
>> stepped through code and it sure seems like the extra information is coming 
>> back from the JDBC driver.
> 
> Are the production and test apps running on the same platform i.e. OS, 
> bitness, etc.

Yes, the production and test apps are running on the same platform. The Java 
apps themselves are physically on the same Linux server. The production and 
test databases reside within the same instance of PostgreSQL.

Also, I should have mentioned up front that I am well aware of the pitfalls of 
using floating point values and also the fact that PostgreSQL's "real" data 
type supports 6 digits of precision. What I do not understand is why my JDBC 
driver is returning more information than what I receive in psql or if I 
operate on a copy of the database. This leads me to believe that more 
information was available at insertion time and is somehow being made available 
to my application even though the data type should only store 6 digits. Let me 
see if I can write a quick little test case.

Tom

--
Tom Duffey
tduf...@trillitech.com
414-751-0600 x102

-- 
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] Floating point error

2013-02-24 Thread Edson Richter


Em 24/02/2013 23:44, Adrian Klaver escreveu:

On 02/24/2013 06:13 PM, Tom Duffey wrote:

Hi Everyone,

Riddle me this. I have a database column of type "real" that gets 
mapped to a Java field of type double via JDBC. We have two 
databases, test and production, and the test database is periodically 
blown away and reloaded from a copy of production. We recently 
noticed that some values do not match when viewed within our 
application on test vs. production. More specifically:


- Selecting values from both test and production DBs using psql shows 
"10.3885" as the value
- The Java app on production shows "10.3884573" while the test app 
shows "10.3885"


I have a hunch that when the value was originally inserted into the 
production DB it probably contained more than the 6 digits supported 
by the real data type. It may have even been exactly the "10.3884573" 
value we see when retrieving via JDBC on production. What I don't 
understand is why when the value gets mapped back to Java via JDBC 
those extra digits are coming back. Can anyone explain this or do you 
think I'm on the wrong track? I stepped through code and it sure 
seems like the extra information is coming back from the JDBC driver.


Are the production and test apps running on the same platform i.e. OS, 
bitness, etc.


According to the Java Language specification, double and real are not 
precise data types because the how it is stored in binary, which in turn 
result in such errors.


See here:
http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html

See also a discussion about how to overcome here:

http://stackoverflow.com/questions/179427/how-to-resolve-a-java-rounding-double-issue

This issue is not exclusive from Java, other languages based on IEEE 754 
standard's suffer of same problem.

That's the reason because BigDecimal exists.

Regards,

Edson





Tom

--
Tom Duffey
tduf...@trillitech.com
414-751-0600 x102










--
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] Floating point error

2013-02-24 Thread Adrian Klaver


On 02/24/2013 06:58 PM, Tom Duffey wrote:


On Feb 24, 2013, at 8:44 PM, Adrian Klaver  wrote:


On 02/24/2013 06:13 PM, Tom Duffey wrote:

Hi Everyone,

Riddle me this. I have a database column of type "real" that gets mapped to a 
Java field of type double via JDBC. We have two databases, test and production, and the 
test database is periodically blown away and reloaded from a copy of production. We 
recently noticed that some values do not match when viewed within our application on test 
vs. production. More specifically:

- Selecting values from both test and production DBs using psql shows "10.3885" 
as the value
- The Java app on production shows "10.3884573" while the test app shows 
"10.3885"

I have a hunch that when the value was originally inserted into the production DB it 
probably contained more than the 6 digits supported by the real data type. It may have 
even been exactly the "10.3884573" value we see when retrieving via JDBC on 
production. What I don't understand is why when the value gets mapped back to Java via 
JDBC those extra digits are coming back. Can anyone explain this or do you think I'm on 
the wrong track? I stepped through code and it sure seems like the extra information is 
coming back from the JDBC driver.


Are the production and test apps running on the same platform i.e. OS, bitness, 
etc.


Yes, the production and test apps are running on the same platform. The Java 
apps themselves are physically on the same Linux server. The production and 
test databases reside within the same instance of PostgreSQL.

Also, I should have mentioned up front that I am well aware of the pitfalls of using 
floating point values and also the fact that PostgreSQL's "real" data type 
supports 6 digits of precision. What I do not understand is why my JDBC driver is 
returning more information than what I receive in psql or if I operate on a copy of the 
database. This leads me to believe that more information was available at insertion time 
and is somehow being made available to my application even though the data type should 
only store 6 digits. Let me see if I can write a quick little test case.



Well I guess you could look in the dump file and see what is recorded there.


Tom




--
Adrian Klaver
adrian.kla...@gmail.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] [JDBC] can't access through SSL

2013-02-24 Thread Adrian Klaver


On 02/24/2013 05:54 PM, Maz Mohammadi wrote:

Hi Adrian,

Thanks for sharing some pointers with me.  You are right, it's not actually an 
JDBC driver issue.  I posted it on jdbc, because I'm accessing it from a jdbc 
client, I thought there might be some security issues with the JDBC driver.

1) I'm running postgres-xc v. 9.1.  I'm "pretty" sure that my postgres setup is 
correct.  Another person from this distribution list help me a bit.  This test shows me 
that the ssl is setup correctly on my server...


Which server? As I understand it Postgres-XC can have multiple clusters 
in use, so I am still not sure which one you are connecting to?




--
postgres-xc@adminuser-VirtualBox:~/datanode2$ psql
psql (PGXC 1.0.0, based on PG 9.1.4)
Type "help" for help.

postgres=# \q
postgres-xc@adminuser-VirtualBox:~/datanode2$ psql -h localhost


To make things easier to debug, use explicit options. The above command 
leaves a lot to env variables and hidden configuration. There is a good 
chance you are not connecting the way you think you are.




psql: FATAL:  connection requires a valid client certificate
FATAL:  no pg_hba.conf entry for host "127.0.0.1", user "postgres-xc", database 
"postgres", SSL off
postgres-xc@adminuser-VirtualBox:~/datanode2$


At this point do none of the Tomcat/JDBC process . Until you solve the 
above, it just gets you to the same error and it confuses the issue.


The first thing to solve is why you are getting two different error 
messages, in particular why it says SSL is off. The second is whether 
the user and database specified in the error are who are trying to 
connect as and the database you are trying to connect to.


Also have you gone through Table 17-3. SSL Server File Usage at link 
below to see if everything is in place:

http://www.postgresql.org/docs/9.2/interactive/ssl-tcp.html

Have you followed Rays suggestion:

'I use openssl to verify the chain, I think that would help you know 
what's going on:


openssl verify -CAfile rootca.crt  user.crt





2) My client is a tomcat server.  I've placed JDBC3 drivers (jar file) in the 
WEB-INF lib directory of my webapp.

3) MY jdbc url is "jdbc:postgresql://localhost:5432:testdb?ssl=true", and 
believe me username and password are correct.

4) Both postgres and tomcat are running on the same machine (an Ubuntu linux 
virtual box).

5) when I try to create a JDBC datasource on my tomcat, I enter the JDBC url + user + 
password, and I'm expecting it to be able to connect to it and at least get a "test 
successful" but I don't.  I get the error that I sent...
"Connection attempt failed: FATAL: connection requires a valid client 
certificate"

6) I've also specified the following java options..
-Djavax.net.ssl.trustStore=/home/adminuser/pentaho/keycerts/mazstore 
-Djavax.net.ssl.trustStorePassword=password

I'll post this on the other distribution list.  BTW, I don't see much in the 
log files under /var/log directory.

-maz



--
Adrian Klaver
adrian.kla...@gmail.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] [JDBC] can't access through SSL

2013-02-24 Thread Michael Paquier

On Mon, Feb 25, 2013 at 10:07 AM, Adrian Klaver wrote:

> 1) Postgres-XC != Postgres. It shares a code base but adds more moving
> parts. Along that line, you will need to be more specific about how you
> have setup Postgres-XC and exactly which part is failing? I for one do not
> use it, so I am not really sure what datanodes, coordinator and gmt
> signify. On a related note XC has its own mailing list(
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general), it may
> turn out there are people there that can answer the question sooner.
>
Adrian is right, pgsql-general is not the place where to discuss about bugs
or problems of settings regarding Postgres-XC, so please send your requests
to the ML indicated by Adrian so as to allow the developers there
(including me, being an active member of the XC community) solving your
problem.


> 2) JDBC. It would seem from this thread and the other that covered this
> topic that JDBC is not really the issue. To make your life simpler I would
> test your setup using psql until you get it running properly, then pull in
> JDBC to see if it adds any problems. Also, it is generally considered not
> good protocol to cross post the same issue to different lists.
>
I think honestly that the problem is not JDBC itself, but the way the nodes
in an XC cluster interact...


> 3) Simple with more detail is better. Create a minimum use case and then
> provide maximum detail of how it was set up and run. For instance:
>
> a) What are the versions of the software?
> b) Where is the client being run from?
> c) Where is the server?
> d) How are both setup?
> e) What is being done between the client and the server?
> f) What do you expect to happen?
> g) What is actually happening?
> i) The actual error message(s)?

Yes, answering those questions on the XC mailing list would be better when
you report your problem there.
What is the node type where error happens?
Have you setup the SSL certificates on all the nodes?
Or anything that would help resolving what you see.
Does the error happen when connecting directly to a Datanode?
-- 
Michael

Re: [GENERAL] autoanalyze criteria

2013-02-24 Thread Stefan Andreatta


On 02/24/2013 12:52 PM, Alban Hertroys wrote:
On Feb 23, 2013, at 14:11, Stefan Andreatta > wrote:


And we are still missing a number for rows updated since the last 
analyse.


In MVCC an update is an insert + delete, so you already got those numbers.

Good point. But because they are an update and a delete, they cancel 
each other out and do not show up in pg_stat_user_tables.n_live_tup - 
and that's the only value for which we have a reference value from the 
time of the last analyze (pg_class.reltuples).


On the other hand, I might again miss something out. I would be most 
happy if anybody could come up with a query to estimate autoanalyze 
trigger conditions from the values we have available now.


Stefan

Re: [GENERAL] autoanalyze criteria

Re: [GENERAL] Dumb question involving to_tsvector and a view

Re: [GENERAL] [JDBC] can't access through SSL

Re: [GENERAL] [JDBC] can't access through SSL

Re: [GENERAL] [JDBC] can't access through SSL

Re: [GENERAL] [JDBC] can't access through SSL

Re: [GENERAL] [JDBC] can't access through SSL

[GENERAL] Floating point error

Re: [GENERAL] Floating point error

Re: [GENERAL] Floating point error

Re: [GENERAL] Floating point error

Re: [GENERAL] Floating point error

Re: [GENERAL] Floating point error

Re: [GENERAL] Floating point error

Re: [GENERAL] Floating point error

Re: [GENERAL] [JDBC] can't access through SSL

Re: [GENERAL] [JDBC] can't access through SSL

Re: [GENERAL] autoanalyze criteria

18 matches

Site Navigation

Mail list logo

Footer information