Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Morten Hustveit <morten(at)eventures(dot)vc>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Date: 2013-11-19 18:14:34
Message-ID: 20131119181434.GP28149@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 19, 2013 at 07:12:32PM +0100, Andres Freund wrote:
> On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
> > > Why change the historical behaviour for savepoints?
> >
> > Because as Tom stated, we already do warnings for other useless
> > transaction commands like BEGIN WORK inside a transaction block:
>
> Which imo is a bad, bad historical accident. I've repeatedly seen this
> hide bugs causing corrupted data in the end.
>
> But even if that weren't a concern, the fact that BEGIN does it one way
> currently doesn't seem very indicative of changing other historical behaviour.

Look at this gem, which returns notice:

test=> ABORT;
NOTICE: there is no transaction in progress
ROLLBACK
test=>

We are all over the map on this! The big question is whether we want to
add some sanity to this, or just leave it alone, and if we leave it
alone, what pattern do we use for the new checks?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-11-19 18:16:26 Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1
Previous Message Mike Blackwell 2013-11-19 18:13:47 Re: stats for network traffic WIP