From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ben Leslie <benno(at)benno(dot)id(dot)au>, Forums postgresql <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Isolation of schema renames |
Date: | 2017-08-10 02:34:37 |
Message-ID: | CAEepm=2x_bHY4+S9r14_jy-v=aeJuUCKk8g-3FWQowWiem3n_Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Aug 10, 2017 at 2:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Ben Leslie <benno(at)benno(dot)id(dot)au> writes:
>> I'm wondering if I can/should expect schema renames to be isolated.
>
> Nope, you should not.
>
> This is not an especially easy thing to fix, because to have the system
> behave as you wish it did, your second transaction would have to be
> ignoring already-committed DDL changes, and it is very easy to show
> examples where that would be fatal.
As mentioned on bug #14691[1], I think it might make theoretical sense
to do SSI checks on system catalogue tables + associated caches
(though I don't claim that's easy). Then a SERIALIZABLE transaction
would abort if you created a conflict cycle with some other session
that has moved your cheese and it was also running in SERIALIZABLE
isolation.
[1] https://www.postgresql.org/message-id/flat/20170605191104.1442.24999%40wrigleys.postgresql.org
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ben Leslie | 2017-08-10 03:21:38 | Re: Isolation of schema renames |
Previous Message | Tom Lane | 2017-08-10 02:14:47 | Re: Isolation of schema renames |