Re: Concurrent psql patch
От | Gregory Stark |
---|---|
Тема | Re: Concurrent psql patch |
Дата | |
Msg-id | 87wsz81xub.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Concurrent psql patch (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: Concurrent psql patch
Re: Concurrent psql patch |
Список | pgsql-patches |
So based on the feedback and suggestions here this is the interface I suggest: \connect& - to open a new connection keeping the existing one \g& - to submit a command asynchronously (like & in the shell) \S [Sess#] - to _S_witch to a different _S_ession - if no connection # specified list available _S_essions \D - _D_isconnect from current session (like ^D in the shell) This leaves no way to submit an asynchronous command without using \g but I'm really not too concerned with that. I don't want to start messing with psql's semicolon parsing behaviour and I'm mainly only concerned with this for regression tests. Another thought I had for the future is a \C command to simulate C-c and send a query cancel. That would let us have regression tests that query cancellation worked. The tests would presumably have to be written using pg_sleep() to ensure they ran for long enough but even then there would be no way to control exactly when the interrupt arrived. Attached is an updated patch. I also found and fixed some missing ResetCancelConn()s. I think I got them all and the behaviour seems correct in practice when cancelling various combinations of synchronous queries, asynchronous queries, and backslash commands. The one thing I wonder about is that I'm a bit concerned I may have introduced an assumption about how many resultsets arrive from a single query. I'll be offline for a few days but I'll be back Monday. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Вложения
В списке pgsql-patches по дате отправления: