On Tue, 11 Jul 2017 20:25:02 GMT, Sönke Ludwig wrote:

On Tue, 11 Jul 2017 19:55:07 GMT, Clinton D Skakun wrote:

Hi guys, I'm trying to figure out how to use my postgres lib in vibe.d routes. The problem is vibe.d uses threads and that causes null pointer errors since it's sharing one pg connection over multiple threads.

Is there a way to assign a connection to each thread? Not sure how the threading works in vibe.d but my problem would be solved if I could pre-connect to a number of connections on startup and distribute them among threads. Say have an array of my PostgresDB. Maybe this won't work, however it seems like the best solution I can think up.

Could anyone help me figure out if this is possible?

Vibe.d, by default doesn't use mutiple threads, but, and that sounds like it could still be the cause multiple [fibers][1] are used. There is vibe.core.connectionpool.ConnectionPool that is meant for cases like these.

An example of how this is used can be seen in the MongoDB driver:
https://github.com/rejectedsoftware/vibe.d/blob/ddbeb6333601381530002529f379b35c20d2eeee/mongodb/vibe/db/mongo/client.d#L62
https://github.com/rejectedsoftware/vibe.d/blob/ddbeb6333601381530002529f379b35c20d2eeee/mongodb/vibe/db/mongo/client.d#L148

BTW, there are at least two other vibe.d compatible Postgres drivers, so maybe it makes sense to join forces there:
https://code.dlang.org/packages/vibe-d-postgresql
https://code.dlang.org/packages/ddb

[1]: http://dlang.org/phobos/core_thread.html#.Fiber

Thanks! I didn't know that existed. So after looking at the Mongo lib and the ConnectionPool lib I got this. Please let me know if I'm on the wrong track: 

...
uint max = 20; // Max connections postgres can lock in vibe.d at once.

this.pgconns = ConnectionPool!(new PostgresDBConnection(() {
  return PostgresDBConnection(connectionInfo);
}), max);
...

Questions about ConnectionPool:

  • When opening a new connection and locking, is the connection later closed when unlocked?
  • ConnectionPool opens new connections gradually and re-uses them as new requests come in? Doesn't look like it's pre-connected at startup.

Okay, this is making sense to be besides the questions above. The code above I'll obviously have to tweak, but it looks like connection pool wraps the connecter and calls the delegate on lock.

I guess pgbouncer would come in handy for a tiny speed upgrade on bursts of requests. E.g. multiple AJAX reqs.