Re: So, why shouldn't SET CONSTRAINTS set a transaction snapshot?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: So, why shouldn't SET CONSTRAINTS set a transaction snapshot?
Date: 2008-12-15 00:47:40
Message-ID: 4945.1229302060@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Well, if you think there's a real backwards compatibility issue, we
>> should just do #2 and be done with it. It's not like it's enough code
>> to really matter in the big scheme of things.

> I don't like it just because it's another kludge in the way we set up
> ActiveSnapshot. I think it would be better if we were simplifying that
> code, not adding more kludges.

> If there's no backwards compatibility argument (and from the looks of
> your patch, perhaps there wouldn't), then I think we should just do #1.

On the whole I think your original instinct was right: there is a
backwards compatibility issue here. Without the kluge added to
trigger.c, this would fail:

BEGIN;
SET CONSTRAINTS ALL IMMEDIATE;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

since a transaction snapshot would be set before reaching the isolation
level change. Since that has worked in the past, it seems there's a
nonnegligible risk of breaking apps. There's no obvious-to-the-user
reason why this ordering shouldn't be okay ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2008-12-15 01:00:03 Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Previous Message Corey Horton 2008-12-15 00:39:39 Re: Re: [SQL] array_to_string(anyarray, text) that was working in 8.1 is not working in 8.3