Re: Hot Standy introduced problem with query cancel behavior

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