Re: Vote totals for SET in aborted transaction

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Mike Mascari <mascarm(at)mascari(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote totals for SET in aborted transaction
Date: 2002-04-27 00:12:23
Message-ID: 5.1.0.14.1.20020427080217.03043810@192.228.128.13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 11:49 AM 4/26/02 -0400, Tom Lane wrote:
>I'm still looking for an example of something that is (a) reasonable
>to set on a per-backend basis, and (b) not reasonable to roll back
>if it's set in a transaction that fails.

The way I see it is if (a) and you don't want it rolled back, you could put
it in a transaction of its own.
BEGIN;
SET backend pref;
COMMIT;

And if that transaction fails, maybe it should :).

So other than for performance, the example should also have a reason to
belong with other statements in a transaction.

Have a nice weekend,
Link.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2002-04-27 01:54:17 Re: Vote totals for SET in aborted transaction
Previous Message Bruce Momjian 2002-04-26 20:33:00 Re: WAL -> Replication