On Thu, 2010-01-07 at 13:12 -0500, Tom Lane wrote: > not fixed the fundamental problem.
(I wasn't saying that I had, only wanted to confirm the problem still existed in the version I was currently working on.) > How critical is it that an > HS-requested query cancel be any more likely to do anything than a > regular query cancel is? Recovery needs to cancel backends in two main cases, which currently throw CONFLICT_MODE_ERROR, though could be separated: (1) Cancel because a snapshot might fail to see data that has now been removed and so get an inconsistent result. We need to abort any subtransactions that have open snapshots, which is really the whole top level xact, unless anyone has a good plan of how to identify (2) Cancel because a backend holds a lock on a table that has been AccessExclusiveLocked on primary. We need to abort as far up the transaction stack as it takes to remove the conflicting lock. We currently abort the whole transaction. Both of those have cases where we might need to abort further than just the top-level subtransaction. We might be able to identify the cases where aborting only the current subtrans is OK, and then just throw normal ERROR for those cases. I think the cases are * when no subxacts exist or * for (1): if no open portals in still active parent sub-transactions * for (2): if any conflicting locks are held by current subxact only -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
