From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Rahila Syed <rahilasyed90(at)gmail(dot)com>, Matt Kelly <mkellycs(at)gmail(dot)com>, Brendan Jurd <direvus(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Surprising behaviour of \set AUTOCOMMIT ON |
Date: | 2016-08-08 15:44:42 |
Message-ID: | CA+TgmoaAkpTgzosur5Ka9rWZPtXwXMA8CqFwRUGN6A110muwMg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 8, 2016 at 11:17 AM, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Mon, Aug 8, 2016 at 11:02 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> On Mon, Aug 8, 2016 at 10:10 AM, Rahila Syed <rahilasyed90(at)gmail(dot)com>
>> wrote:
>> > Thank you for inputs everyone.
>> >
>> > The opinions on this thread can be classified into following
>> > 1. Commit
>> > 2. Rollback
>> > 3. Error
>> > 4. Warning
>> >
>> > As per opinion upthread, issuing implicit commit immediately after
>> > switching
>> > autocommit to ON, can be unsafe if it was not desired. While I agree
>> > that
>> > its difficult to judge users intention here, but if we were to base it
>> > on
>> > some assumption, the closest would be implicit COMMIT in my
>> > opinion.There is
>> > higher likelihood of a user being happy with issuing a commit when
>> > setting
>> > autocommit ON than a transaction being rolled back. Also there are
>> > quite
>> > some interfaces which provide this.
>> >
>> > As mentioned upthread, issuing a warning on switching back to autocommit
>> > will not be effective inside a script. It won't allow subsequent
>> > commands to
>> > be committed as set autocommit to ON is not committed. Scripts will have
>> > to
>> > be rerun with changes which will impact user friendliness.
>> >
>> > While I agree that issuing an ERROR and rolling back the transaction
>> > ranks
>> > higher in safe behaviour, it is not as common (according to instances
>> > stated
>> > upthread) as immediately committing any open transaction when switching
>> > back
>> > to autocommit.
>>
>> I think I like the option of having psql issue an error. On the
>> server side, the transaction would still be open, but the user would
>> receive a psql error message and the autocommit setting would not be
>> changed. So the user could type COMMIT or ROLLBACK manually and then
>> retry changing the value of the setting.
>>
>> Alternatively, I also think it would be sensible to issue an immediate
>> COMMIT when the autocommit setting is changed from off to on. That
>> was my first reaction.
>>
>> Aborting the server-side transaction - with or without notice -
>> doesn't seem very reasonable.
>>
>
> Best of both worlds?
>
> IF (ON_ERROR_STOP == 1)
> THEN (treat this like any other error)
> ELSE (send COMMIT; to server)
No, that's not a good idea. The purpose of ON_ERROR_STOP is something
else entirely, and we shouldn't reuse it for an unrelated purpose.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-08-08 16:26:28 | Re: Heap WARM Tuples - Design Draft |
Previous Message | David G. Johnston | 2016-08-08 15:17:12 | Re: Surprising behaviour of \set AUTOCOMMIT ON |