Re: PGStream synchronization
От | Maciek Sakrejda |
---|---|
Тема | Re: PGStream synchronization |
Дата | |
Msg-id | 895e58dd0908261737t20f5b7dbsd9ae546a34264a7@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PGStream synchronization (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: PGStream synchronization
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: