On 19 helmi, 12:20, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > On 19 févr. 2013, at 11:04, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > > > Maybe we need another setting for what to do in request.start. It does > > seem somewhat likely that users could do SET SEARCH_PATH in middleware > > to support multitenant setups for example, and expect that set to go > > away when connection is closed after the request. Any other SET is a > > likely candidate for problems in PostgreSQL, and I am sure other DBs > > have their equivalent of session state, too. (In this case doing RESET > > ALL; run connection setup again is the right thing to do in > > PostgreSQL). > > > It would be nice to support this use case, but just documenting this > > change clearly in the release notes, and point out that if you have > > such requirements, then set max_age to 0. More features can always be > > added later on. > > Yes, the short term solution in this case is to set max_age to 0. > > I think the long term solution is to modify such middleware to revert its > effects in process_response() — or reset everything in process_request(). > > I agree with Carl that I should document this thoroughly.
Yeah, just doing the reset manually in middleware should be good enough. > > I think a good approach would be to mark the connection potentially > > broken on errors in queries, and then in request_finished check for > > this potentially broken flag. If flag set, then and only then run > > ping() / select 1. So, this is a slight modification of no. 3 where > > one can mark the connection potentially broken liberally, but the > > connection is swapped only when the ping fails, and only in > > request_finished. For most requests there should be no overhead as > > errors in queries are rare. > > This is an interesting idea. Django already catches database exceptions in > execute() to re-raise them. We could simply set the flag there. > > > BTW the remark above in Aymeric's post that persistent connections > > can't make things worse: I don't believe this. Persistent connections > > will keep the broken connection from request to request, and at least > > on PostgreSQL a broken connection is correctly closed in request > > finish. > > https://code.djangoproject.com/ticket/15802says it isn't — although I haven't > confirmed that this bug still exists. I just tried this and broken connections are closed correctly at least in master. First paragraph of comment https://code.djangoproject.com/ticket/15802#comment:20 says this is already fixed in 1.4. The open part of the ticket seems to be about 1.3 (which is not going to be fixed anyways) or automatic connection swapping (which is dangerous). So maybe it is time to reclose the ticket? - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
