| 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: | Whole Thread | Raw Message | 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 |