> Tatsuo>Interesting. What would happen if a user changes some of GUC > parameters? Subsequent session accidentally inherits the changed GUC > parameter? > > Yes, that is what happens.
Ouch. > The idea is not to mess with gucs. > > Tatsuo>There's nothing wrong with DICARD ALL > Tatsuo>"DISCARD ALL" is perfect for this goal. > > It looks like you mean: "let's reset the connection state just in case". > I see where it might help: e.g. when providing database access to random > people who might screw a connection in every possible way. Yes, that's what clients of pgpool is expecting. Clients do not want to change their applications which were working with PostgreSQL without pgpool. > Just in case: do you think one should reset CPU caches, OS filesystem > caches, DNS caches, bounce the application, and bounce the OS in addition > to "discard all"? Aparently no, because that is different from what PostgreSQL is doing when backend exits. > Why reset only "connection properties" when we can reset everything to its > pristine state? You can propose that kind of variants of DISCARD command. PostgreSQL is an open source project. > Just in case: PostgreSQL does not execute "discard all" on its own. > If you mean "pgpool is exactly like reconnect to postgresql but faster > since connection is already established", then OK, that might work in some > cases (e.g. when response times/throughput are not important), however why > forcing "you must always start from scratch" execution model? I'm not doing that. I do not ask all the people to use pgpool. People can choose whatever tools he/she thinks suitable for their purpose. > Developers are not that dumb, and they can understand that "changing gucs > at random is bad". > > When a connection pool is dedicated to a particular application (or a set > of applications), then it makes sense to reuse statement cache for > performance reasons. > Of course, it requires some discipline like "don't mess with gucs", however > that is acceptable and it is easily understandable by developers. I'm not against such a developer's way. If you like it, you can do it. Nobody disturbs you. I just want to say that not all the client want that way. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
