From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | chris+postgresql(at)qwirx(dot)com |
Cc: | pgsql-docs(at)postgresql(dot)org |
Subject: | Re: SET CONSTRAINTS ALL IMMEDIATE affects SET TRANSACTION READ ONLY |
Date: | 2016-09-09 16:39:06 |
Message-ID: | 5491.1473439146@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
chris+postgresql(at)qwirx(dot)com writes:
> We found that normally, if you execute SET TRANSACTION READ ONLY, it
> prevents COMMIT from happening if any data has been changed in the
> transaction (and we have been relying on this for safety).
This seems like a truly bizarre expectation.
I wouldn't really imagine that it's sensible to set READ ONLY
mid-transaction at all, but if it means anything to do that, surely
it ought to mean that no updates can happen *after* you set it.
Which is what your examples seem to be doing. (I'm assuming something
you didn't state, which is that you have a deferred constraint that
causes a commit-time update in reaction to the explicit UPDATE; otherwise
SET CONSTRAINTS ALL IMMEDIATE shouldn't have any effect at all.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christos Evaggelou | 2016-09-11 08:12:08 | Suggestion - Document a currently undocumented(?) feature - SELECT Table FROM Table |
Previous Message | Satoshi Nagayasu | 2016-09-09 14:03:09 | Re: REINDEX and blocking SELECT queries |