Re: [GENERAL] currval and DISCARD ALL

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