On Thu, Apr 02, 2015 at 01:21:17PM -0400, Alex Vandiver wrote: > On Thu, 2 Apr 2015 09:30:13 -0500 "k...@rice.edu" <k...@rice.edu> wrote: > > We are working on an upgrade from RT 3.8.x to RT 4.2.x to get to a > > supported version of RT and take advantage of the new features and > > enhancements. In order to manage the PostgreSQL connections, we are > > using pgbouncer. Pgbouncer has several types of pooling that can be > > used: session, transaction and statement. The 'transaction' method > > re-uses existing DB connections on a transaction (BEGIN/COMMIT) > > boundary, while 'session' uses the same DB connection for each > > fastCGI RT instance. > > > > With RT 3.8.x we initially tried to use 'transaction' pooling, but > > ended up needing to move to 'session' pooling because updates were > > ending up in the wrong RT ticket. Is 'transaction' pooling not > > usable? It would really help our multi-instance support if we could > > use it instead of 'session'. If it can be used, is there something > > that needs to be done configuration-wise to have it work. Thank you > > for any information that you can give. > > RT doesn't make sufficient use of database transactions that I think > "transaction" will be reliable; I expect "session" is the best you can > get. I'm not aware of any configuration knobs that would affect this; > fixing it would take some internals development. > - Alex >
Thank you for the update. That is the behavior that we have observed and will stick with the "session" pooling option. Regards, Ken