Tatsuo Ishii <[EMAIL PROTECTED]> writes: > First, it's not a particular problem with pgpool. As far as I know any > connection pool solution has exactly the same problem. Second, it's > easy to fix if PostgreSQL provides a functionarity such as:"drop all > temporary tables if any".
I don't like that definition exactly --- it would mean that every time we add more backend-local state, we expect client drivers to know to issue the right incantation to reset that kind of state. I'm thinking we need to invent a command like "RESET CONNECTION" that resets GUC variables, drops temp tables, forgets active NOTIFYs, and generally does whatever else needs to be done to make the session state appear virgin. When we add more such state, we can fix it inside the backend without bothering clients. I now realize that our "RESET ALL" command for GUC variables was not fully thought out. We could possibly redefine it as doing the above, but that might break some applications ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match