From: | "Luigi Antognini" <luigi370(at)produs(dot)ch> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Transaction isolation when applying DDLs |
Date: | 2010-02-24 09:26:02 |
Message-ID: | EE325B6EF63E42FC85B92025F8ABAA64@produs.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello,
I'm considering to apply DDLs (such as altering columns or constraints)
without stopping the application running against the database.
This is quite unusual but could work under certain circumstances, because
the application is aware
of any change applied to the underlying database structures.
By experimenting with transactional DDL I noticed that the database truly
handles them atomically,
even in complex cases, up to hundreds or thousands of DDL statements.
My question: How is transaction isolation defined when applying DDLs?
Some experiments showed this behaviour:
1. external transactions seems to be fully isolated
from column adds & drops in a DDL transaction
(structurally speaking, a repeateable read)
2. external transactions seems to be fully isolated
from dropping and recreating a column in a DDL transaction
(structurally speaking, a repeateable read)
3. external transactions report an error like "could not open relation
with OID xxxxxx"
when the DDL transaction drops and recreates a single table, all tables or
an entire schema
This is more than acceptable, as dropping/recreating structures is not
likely to happen in a productive system.
What else should I know/consider?
Thanks
Luigi Antognini
From | Date | Subject | |
---|---|---|---|
Next Message | adam_pgsql | 2010-02-24 11:00:34 | Re: "make check" failed on 8.4.2 install |
Previous Message | Albe Laurenz | 2010-02-24 09:12:38 | Re: Explaining duplicate rows in spite of unique index |