| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Autonomous Transaction is back |
| Date: | 2015-08-07 15:26:08 |
| Message-ID: | CA+TgmoaUSQg6Le-gznUuLb6J+nLoH+Lw37CqPRb19gv4mpQbaw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 6, 2015 at 11:04 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> I don't necessarily disagree with what you're saying, but it's not
> clear to me what the proposed behavior is. Since the AT can commit
> before the outer, ISTM *any* ungranted lock requested by the AT but
> held by the outer leads to either A: functional deadlock (regardless
> of implementation details) or B: special behavior.
I don't accept that. We've already GOT cases where a query can be
suspended and other queries can be running in the same backend. You
can do that via cursors. Those cases work fine, and the deadlock
detector doesn't know anything about them. How is this any different?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-08-07 15:40:50 | Re: Reduce ProcArrayLock contention |
| Previous Message | Andres Freund | 2015-08-07 15:17:29 | Re: Reduce ProcArrayLock contention |