Right. I did say I wasn't happy with it...
Would introducing message-level synchronization be the way to go,
then? As I see it, there are four possible approaches:
1. Cancel before close--what I just protoyped in the previous patch.
Pros: straighforward
Cons: overkill for most applications; semantics are ugly (queries
should not be canceled)
2. Status quo:
Pros: status quo, works in single-threaded case
Cons: protocol violations, possibly swallowed Terminate messages *and*
bad data in multi-threaded COPY
3. Introduce protocol-message-level synchronization
Pros: cleanest solution conceptually
Cons: may incur significant additional synchronization overhead,
significant changes in core code
4. Synchronize close() like other QueryExecutorImpl like other
connection activities
Pros: also straightforward
Cons: may block indefinitely on long-running queries or open copy
(although could additionally be made to trigger a CopyFail if a copy
operation is in progress)
I tend to agree that (1) is unworkable as a general-purpose solution.
I'm not sure how you guys feel about (2), but protocol violations seem
like a really, really ugly problem, even if they are only on closing
the connection. (3) is probably ideal, barring performance problems.
(4) may also be workable, but having close() block on currently
running queries is probably not what we want to do.
Any thoughts?
--
Maciek Sakrejda | Software Engineer | Truviso
(650) 242-3500 Main
(650) 242-3501 F
msakrejda@truviso.com
www.truviso.com
