Skip site navigation (1) Skip section navigation (2)

Re: Vote on SET in aborted transaction

From: Vince Vielhaber <vev(at)michvhf(dot)com>
To: Michael Loftis <mloftis(at)wgops(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote on SET in aborted transaction
Date: 2002-04-24 18:20:23
Message-ID: Pine.BSF.4.40.0204241420040.19948-100000@paprika.michvhf.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 24 Apr 2002, Michael Loftis wrote:

> Vote number 1 -- ROLL BACK

I agree..  Number 1 - ROLL BACK

>
> Bruce Momjian wrote:
>
> >OK, would people please vote on how to handle SET in an aborted
> >transaction?  This vote will allow us to resolve the issue and move
> >forward if needed.
> >
> >In the case of:
> >
> >	SET x=1;
> >	BEGIN;
> >	SET x=2;
> >	query_that_aborts_transaction;
> >	SET x=3;
> >	COMMIT;
> >
> >at the end, should 'x' equal:
> >
> >	1 - All SETs are rolled back in aborted transaction
> >	2 - SETs are ignored after transaction abort
> >	3 - All SETs are honored in aborted transaction
> >	? - Have SETs vary in behavior depending on variable
> >
> >Our current behavior is 2.
> >
> >Please vote and I will tally the results.
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>


Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev(at)michvhf(dot)com    http://www.pop4.net
         56K Nationwide Dialup from $16.00/mo at Pop4 Networking
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2002-04-24 18:24:48
Subject: Re: Inefficient handling of LO-restore + Patch
Previous:From: Igor KovalenkoDate: 2002-04-24 18:19:22
Subject: Re: "make report"

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group