On Tue, Dec 13, 2016 at 2:05 PM, Andrew Borodin <boro...@octonica.com> wrote: > 2016-12-13 12:55 GMT+05:00 amul sul <sula...@gmail.com>: >> I think background-session code is not that much deviated from >> pg_background code, > It is not derived, though it is not much deviated. background sessions > code do not have detailed exceptions and code comments, but it is > doing somewhat similar things. >>IIUC background-session patch we can manage to >> reuse it, as suggested by Robert. This will allow us to maintain >> session in long run, we could reuse this session to run subsequent >> queries instead of maintaining separate worker pool. Thoughts? > > One API to deal with both features would be much better, sure. > "Object" like sessions pool are much easier to implement on top of > session "object" then on top of worker process, PIDs etc. > >>> 4. Query as a future (actually it is implemented already by >>> pg_background_result) >>> 5. Promised result. Declare that you are waiting for data of specific >>> format, execute a query, someone (from another backend) will >>> eventually place a data to promised result and your query continues >>> execution. >> >> Could you please elaborate more? >> Do you mean two way communication between foreground & background process? > > It is from C++11 threading: future, promise and async - these are > related but different kinds of aquiring result between threads. > Feature - is when caller Cl start thread T(or dequeue thread from > pool) and Cl can wait until T finishes and provides result. > Here waiting the result is just like selecting from pg_background_result(). > Promise - is when you declare a variable and caller do not know which > thread will put the data to this variable. But any thread reading > promise will wait until other thread put a data to promise. > There are more parallelism patterns there, like async, deffered, lazy, > but futures and promises from my point of view are most used. > Nice, thanks for detailed explanation.
We can use shm_mq infrastructure to share any kind of message between two processes, but perhaps we might end up with overestimating what originally pg_background could used for - the user backend will launch workers and give them an initial set of instruction and then results will stream back from the workers to the user backend. >>> 6. Cancelation: a way to signal to background query that it's time to >>> quit gracefully. >> Let me check this too. > I think Craig is right: any background query must be ready to be shut > down. That's what databases are about, you can safely pull the plug at > any moment. SIGTERM is handled in current pg_background patch, user can terminate backend execution using pg_cancel_backend() or pg_terminate_backend() as shown below: postgres=> select pg_background_launch('insert into foo values(generate_series(1,100000000))'); pg_background_launch ---------------------- 67069 (1 row) postgres=> select pg_terminate_backend(67069); pg_terminate_backend ---------------------- t (1 row) postgres=> select * from pg_background_result(67069) as (x text); ERROR: terminating connection due to administrator command CONTEXT: background worker, pid 67069 postgres=> Thanks & Regards, Amul -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers