On 04/19/2013 06:50 AM, Robert Haas wrote:
On Wed, Apr 17, 2013 at 6:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
No, it's a critical tool in complexity management. When you're dealing
with systems as complicated as a database, every little non-orthogonal
detail adds up. DISCARD ALL has a clear definition in terms of simpler
commands, and it's going to stay that way. Either this is worth a
subcommand, or it's not worth worrying about at all.
And then you did this:
commit e309739670ac8c2fa0b236d116fcd44b0522025a
Author: Tom Lane <t...@sss.pgh.pa.us>
Date: Thu Nov 27 00:28:06 2008 +0000
Tweak wording of DISCARD ALL description to avoid giving the impression
that the presented list of equivalent operations is meant to be the
primary definition of what it does. Per comment from Guillaume Smet.
So it seems to me that we pretty much already made a decision that the
controlling definition of DISCARD ALL is that, as the fine manual says
"DISCARD ALL resets a session to its original state". Whatever
decision we make now ought to be consistent with that.
IOW, I don't care whether we introduce a new subcommand or not. But I
*do* think that that we ought to make our best effort to have DISCARD
ALL clear everything that smells like session-local state. Random
incompatibilities between what you see when running under a connection
pooler and what you see when connecting the DB directly are *bad*,
regardless of whether a well-designed application should be relying on
those particular things or not. The whole point of having a
transparent connection pooler is that it's supposed to be transparent
to the application.
I understand the confusion on what constitutes ALL in DISCARD, though I
am not sure about the incompatibility argument. The OP is using the
transaction mode from pgBouncer and from their docs:
http://wiki.postgresql.org/wiki/PgBouncer
"Transaction pooling
Server connection is assigned to client only during a transaction. When
PgBouncer notices that transaction is over, the server will be put back
into pool.
This mode breaks few session-based features of PostgreSQL. You can use
it only when application cooperates by not using features that break.
See the table below for incompatible features."
" Note that 'transaction' pooling breaks client expectations of server
by design and can be used only if application cooperates by not using
non-working features."
"
Session pooling
server_reset_query = DISCARD ALL;
This will clean everything.
Transaction pooling
server_reset_query =
Yes, empty. In transaction pooling mode the clients should not use any
session-based features, so there is no need to clean anything. The
server_reset_query would only add unnecessary round-trip between
transactions and would drop various caches that the next transaction
would unnecessarily need to fill again."
I could see the argument for a transparent pooler where it part of the
core code. Not sure if it is the projects responsibility to maintain
transparency with the feature matrices of external projects.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Adrian Klaver
adrian.kla...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
