On Tue, Sep 30, 2014 at 1:53 PM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
As Steve says, it should be possible to ensure that the pooler doesn't
take the session away from you in between, by wrapping the whole thing
in BEGIN/COMMIT if nothing else. If the pooler will take away a session
intra-transaction, it is 100% broken and dangerous, and you need to get
another one.
I'm using Go's database/sql connection pooling from its stdlib, which does per-transaction pooling and otherwise doesn't expose a whole lot of control to the user. (Presumably to make it something you don't have to think about; yet here I am thinking about it a great deal.)
If I understand you both correctly, wrapping every statement in a transaction will have no appreciable difference in speed or level of concurrency, since that wrapping would otherwise already happen under the hood. Since the Go pooler respects transactions, that seems like the answer to me.
And if the execution of the set command itself turns out to be costly (though that sounds unlikely) there is a backup plan involving a series of user accounts with different timeouts that will at least allow me to approximate the limits that I want.
Thank you both!
-William
