Re: [HACKERS] Proposal for async support in libpq
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Proposal for async support in libpq |
Дата | |
Msg-id | 199804172026.QAA29465@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Proposal for async support in libpq (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Proposal for async support in libpq
Re: [HACKERS] Proposal for async support in libpq |
Список | pgsql-hackers |
> > Bruce Momjian <maillist@candle.pha.pa.us> writes: > > This all looks good. Another thing we really need it to be able to > > cancel queries. This would be a big win, and looks like it could fit > > into the scheme here. > > I thought about proposing a PQcancelAsync that would cancel the active > query-in-progress. But that would require support on the backend side, > and I am far from competent to make it happen. (libpq is simple enough > that I'm not afraid to rewrite it, but making major mods to the backend > is another story. I just got here this week...) > > If anyone who does know what they're doing is willing to make the > necessary backend mods, I'm all for it. The libpq side would be > easy enough. > > How would such cancellation interact with transactions, btw? Would > you expect it to roll back only the current command, or abort the > whole transaction? We'd also have to consider corner cases, like > when the backend has already finished the query by the time it gets > the cancel request. It is pretty easy, just an elog(ERROR) would do it. The issue is allowing the backend to see the request. We can put some checks in tcop/postgres.c as it moves from module to module, and something in the executor to check for the cancel, and do an elog(ERROR). It would be nice if it arrived as out-of-band data, so we could check for input quickly without having to actually process it if it is not a cancel notification. The out-of-band data will send a SIGURG signal to the backend, and we can set a global variable, and check the variable at various places. To do all this, we need to be able to send a query, and not have it block, and it seems you are giving us this capability. You supply the indication to the backend, and I will see that the backend processes it properly. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: