Re: [GENERAL] currval and DISCARD ALL - Mailing list pgsql-hackers

On 04/19/2013 06:50 AM, Robert Haas wrote:
> On Wed, Apr 17, 2013 at 6:17 PM, Tom Lane <tgl@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 <tgl@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.klaver@gmail.com