RESET CONNECTION idea

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RESET CONNECTION idea

Bruce Momjian-2
Our current RESET CONNECTION TODO item is:

        * Add RESET CONNECTION command to reset all session state
       
          This would include resetting of all variables (RESET ALL), dropping of
          temporary tables, removing any NOTIFYs, cursors, open transactions,
          prepared queries, currval()s, etc.  This could be used  for connection
          pooling.  We could also change RESET ALL to have this functionality.
          The difficult of this features is allowing RESET ALL to not affect
          changes made by the interface driver for its internal use.  One idea
          is for this to be a protocol-only feature.  Another approach is to
          notify the protocol when a RESET CONNECTION command is used.

I know we have GUC variables that are passed automatically to the
client.  I assume varaible changes are also automatically sent to the
client.  

What if we create a 'reset_connection' guc that is initially false, and
is set to 'true' when someone resets a connection. Then, when it
happens, the client finds out, reconfigures whatever it needs, then sets
the value back to 'false'.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  [hidden email]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org
Reply | Threaded
Open this post in threaded view
|

Re: RESET CONNECTION idea

Tom Lane-2
Bruce Momjian <[hidden email]> writes:
> What if we create a 'reset_connection' guc that is initially false, and
> is set to 'true' when someone resets a connection. Then, when it
> happens, the client finds out, reconfigures whatever it needs, then sets
> the value back to 'false'.

It seems to me that one could trivially break any driver that depends on
such a thing, just by issuing
        SET reset_connection = true;
Then the driver will think the connection has been reset when it has
not, and become completely confused about the actual connection state.

You can't avoid this by making the variable protected, because then the
driver itself would be unable to clear it.

In short I don't think this can work.  We'd need an actual protocol
message specifically to report RESET CONNECTION.  The loss of backwards
compatibility is not necessarily a bad thing; arguably, you *want*
any client library that doesn't recognize the message to fail, since
otherwise it will be out of sync about the connection state.

Alternatively, depending on what level of client software you think
should be issuing such things, we could make the RESET request be a
new protocol message rather than a SQL statement.  Then it couldn't
even be invoked by a non-updated client, and so the compatibility
problem goes away.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [hidden email] so that your
      message can get through to the mailing list cleanly