Re: \set AUTOROLLBACK ON

From: David Fetter <david(at)fetter(dot)org>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Joel Jacobson <joel(at)trustly(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Lukas Gratte <lukas(at)trustly(dot)com>
Subject: Re: \set AUTOROLLBACK ON
Date: 2017-06-26 20:25:17
Message-ID: 20170626202517.GE10211@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 26, 2017 at 12:35:47PM -0700, David G. Johnston wrote:
> On Mon, Jun 26, 2017 at 12:19 PM, David Fetter <david(at)fetter(dot)org> wrote:
>
> > On Mon, Jun 26, 2017 at 04:00:55PM +0200, Joel Jacobson wrote:
> > > Hi hackers,
> > >
> > > A colleague of mine wondered if there is a way to always run
> > > everything you type into psql in a db txn and automatically rollback
> > > it as soon as it finish.
> > > I couldn't think of any way to do so, but thought it would be a nice
> > > feature and probably quite easy to add to psql, so I thought I should
> > > suggest it here.
> > >
> > > The typical use-case is you are doing something in production that you
> > > just want to
> > > a) test if some query works like expected and then rollback
> > > or,
> > > b) read-only queries that should not commit any changes anyway, so
> > > here the rollback would just be an extra layer of security, since your
> > > SELECT might call volatile functions that are actually not read-only
> > >
> > > Thoughts?
> >
> > Multi-statement transactions:
> >
> > Would flavor of BEGIN TRANSACTION undo the feature?
> > If not, would it auto-munge COMMIT into a ROLLBACK?
> >
>
> We already have SET TRANSACTION READ ONLY.

Now there's an interesting and potentially fruitful idea. How about
exposing GUCs to psql? That way, it'd be possible to put (some
transformation of) them in the prompt, etc.

> > Side effects:
> >
> > Let's imagine you have a function called
> > ddos_the_entire_internet(message TEXT), or something less drastic
> > which nevertheless has side effects the DB can't control.
> >
> > How should this mode handle it? Should it try to detect calls to
> > volatile functions, or should it just silently fail to do what
> > it's promised to do?
> >
>
> ​It doesn't need to promise anything more than what happens today if
> someone manually keys in
>
> BEGIN;
> [...]
> ROLLBACK;
>
> ​using psql prompts.

Seems reasonable :)

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-06-26 20:26:00 Re: Reducing pg_ctl's reaction time
Previous Message Andres Freund 2017-06-26 20:23:56 Re: Reducing pg_ctl's reaction time