On Thu, Aug 6, 2015 at 11:04 PM, Merlin Moncure <mmonc...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
