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.
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 |