| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This is actually caused by two bugs:
- The query that caused the error is not removed from the queue, so it
will be executed again. (triggering another error)
- The select_write() is still active on the socket, even when we don't
have anything to write.
I've been aware of this bug for quite a while, but could never track it
down. Now I finally know what really happened when my applications got
in an infinite loop.
|
|
|
|
|
|
Queries will now be queued untill we are connected. This may be what
you want in some cases, but may not in other cases... At least it's the
easiest way of handling DB requests without being connected.
|
|
It took me an entire day just to find out why the heck PoCo::Pg wouldn't
always receive a dbi_canread event when the query result is available.
Found out it was because pg_notifies does, apparently, read something
from the socket. (But apparently not in a blocking way... so it was hard
to detect...)
|
|
|
|
|
|
No need to for named arguments if they aren't likely to change and
you'll often need to specify all arguments, anyway.
|
|
This is something that should be specified in the dsn argument, as it's
application-specific.
|
|
Completely untested, though
|
|
|
|
|
|
|
