Dear Jeroen,
Thanks for your early response.
On 2005.12.21. 6:03, Jeroen T. Vermeulen wrote:
On Wed, December 21, 2005 01:02, Szûcs Gábor wrote:
pqxx::connection's documentation says:
The advantage of having an "immediate" connection (represented by this
class) is that errors in setting up the connection will probably occur
during construction of the connection object, rather than at some later
point further down your program.
This is what seems to be hurt here.
At the point where you want a definite answer (either a working connection
or an exception), invoke the connection's activate() method. This will
work even if you're using a lazy or asynchronous connection.
Sounds good. I'll try that, still, may I suggest including some hint on this
in the abovementioned part of the documentation? ("probably occur during
construction") Something like "To make things more sure, invoke activate()
after the constructor." Since I expect connection to activate right in
construction time, could you also write something about why isn't it done?
The documentation of activate() doesn't give (me) a hint about that either.
Also, don't bother with the reconnect() stuff. The connection class has
(snip) Did consider that, and will consider again. There are some things
however, that may not be supported by pqxx::connection's standard mechanism.
- I use reconnect() also for first-time connect, but that can be done
explicitly within the connection.
- I'd like to make robust logging, silencing the log when there are 1000s of
connection failures in seconds.
- I need to log connections and failures explicitly, and I don't know if the
connection class can support this (like my afterConnect event).
- I need the afterConnect event. Currently, it's only two LISTENs (I know
about the notifier (trigger) classes but I didn't dare to use them yet) and
one nextval (not sure if necessary; maybe I need it only once per Connection
object) but this repertoire may widen.
If there is a way to still log all connection attempts (better: control
which ones to log, see mass failures above), and I can incorporate the
notifier classes, I may at least temporarily discard this piece of code. I
just need some nudge and encouragement :)
Well, according to the log you post, the backend is expecting a password
and you're not supplying one in the connection string. I don't think the
server can be set up to trust the system's user authentication in this
When pg_hba.conf is set to accept "ident sameuser" from this one trusted IP,
it works. When this line is commented, the server falls back to a more
general row, matching (part of) the LAN, that requires password auth. This
is the case we are talking about. The server is right, transaction's
exception is right, I only expected this exception right from connection's
constructor.
make that accessible somehow. But in the end, this is exactly the kind of
situation that exceptions are for. When you get an error, why not let the
exception propagate upwards until it gets to a point where the problem can
be handled?
I've been thought about that, but I'm a very bad and lazy programmer who
doesn't want to fill the code with catches esp. when I'm not even interested
in the outcome of the query. ;)
--
G.
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
