Re: [HACKERS] background sessions

On 4/4/17 10:28, Robert Haas wrote: > So is this patch going anywhere? Not right now. It will take some time to sort out your feedback and do some refactoring. I will close the patch for now. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

Re: [HACKERS] background sessions

On Sat, Mar 18, 2017 at 1:10 PM, Robert Haas wrote: > On Sat, Mar 18, 2017 at 10:59 AM, Petr Jelinek > wrote: >>> shm_redirect_to_shm_mq() wasn't really designed to be used this way; >>> it's designed for use by the worker, not the process

Re: [HACKERS] background sessions

On Sat, Mar 18, 2017 at 10:59 AM, Petr Jelinek wrote: >> shm_redirect_to_shm_mq() wasn't really designed to be used this way; >> it's designed for use by the worker, not the process that launched it. >> If an error occurs while output is redirected, bad things will

Re: [HACKERS] background sessions

On 15/03/17 17:58, Robert Haas wrote: > On Wed, Mar 15, 2017 at 6:43 AM, Pavel Stehule > wrote: >> I don't understand - CHECK_FOR_INTERRUPTS called from executor implicitly. > > True. So there shouldn't be any problem here. I'm confused as can be > about what you want

Re: [HACKERS] background sessions

On Wed, Mar 15, 2017 at 6:43 AM, Pavel Stehule wrote: > I don't understand - CHECK_FOR_INTERRUPTS called from executor implicitly. True. So there shouldn't be any problem here. I'm confused as can be about what you want changed. Some review of the patch itself: +

Re: [HACKERS] background sessions

2017-03-15 0:44 GMT+01:00 Robert Haas : > On Tue, Mar 14, 2017 at 4:54 PM, Pavel Stehule > wrote: > >> I don't understand. The only way you'd need a server restart is if a > >> background process wasn't responding to SIGTERM, and that's a bug > >>

Re: [HACKERS] background sessions

On Tue, Mar 14, 2017 at 4:54 PM, Pavel Stehule wrote: >> I don't understand. The only way you'd need a server restart is if a >> background process wasn't responding to SIGTERM, and that's a bug >> independent of anything this patch does. It would be cause by the >>

Re: [HACKERS] background sessions

2017-03-14 19:08 GMT+01:00 Robert Haas : > On Tue, Mar 14, 2017 at 3:31 AM, Pavel Stehule > wrote: > > Very often strategy can be recheck of parent process in some waiting > > cycles. It should not to impact performance. > > I think that's going

Re: [HACKERS] background sessions

On Tue, Mar 14, 2017 at 3:31 AM, Pavel Stehule wrote: > Very often strategy can be recheck of parent process in some waiting > cycles. It should not to impact performance. I think that's going to be hard to arrange, and I think it isn't necessary. If the leader wants

Re: [HACKERS] background sessions

2017-03-13 21:22 GMT+01:00 Robert Haas : > On Sat, Mar 11, 2017 at 10:11 AM, Pavel Stehule > wrote: > > 2017-03-09 14:52 GMT+01:00 Peter Eisentraut > > : > >> > >> On 3/8/17 14:22, Pavel Stehule wrote: > >> > 1.

Re: [HACKERS] background sessions

On Sat, Mar 11, 2017 at 10:11 AM, Pavel Stehule wrote: > 2017-03-09 14:52 GMT+01:00 Peter Eisentraut > : >> >> On 3/8/17 14:22, Pavel Stehule wrote: >> > 1. will be background session process closed automatically when parent >> > process

Re: [HACKERS] background sessions

2017-03-09 14:52 GMT+01:00 Peter Eisentraut : > On 3/8/17 14:22, Pavel Stehule wrote: > > 1. will be background session process closed automatically when parent > > process is closed? > > If the communications queue goes away the process will eventually die. >

Re: [HACKERS] background sessions

On 3/8/17 14:22, Pavel Stehule wrote: > 1. will be background session process closed automatically when parent > process is closed? If the communications queue goes away the process will eventually die. This is similar to how a backend process will eventually die if the client goes away. Some

Re: [HACKERS] background sessions

Hi 2017-03-01 3:35 GMT+01:00 Peter Eisentraut : > > For additional entertainment, I include patches that integrate > > background sessions into dblink. So dblink can open a connection to a > > background session, and then you can use the existing dblink

Re: [HACKERS] background sessions

> For additional entertainment, I include patches that integrate > background sessions into dblink. So dblink can open a connection to a > background session, and then you can use the existing dblink functions > to send queries, read results, etc. People use dblink to make > self-connections to

Re: [HACKERS] background sessions

2017-01-12 9:01 GMT+05:00 Peter Eisentraut : > On 1/10/17 10:58 AM, Robert Haas wrote: >> On Thu, Dec 29, 2016 at 5:18 PM, Peter Eisentraut >> wrote: >>> For additional entertainment, I include patches that integrate >>>

Re: [HACKERS] background sessions

On 1/10/17 10:58 AM, Robert Haas wrote: > On Thu, Dec 29, 2016 at 5:18 PM, Peter Eisentraut > wrote: >> For additional entertainment, I include patches that integrate >> background sessions into dblink. So dblink can open a connection to a >> background session,

Re: [HACKERS] background sessions

On Thu, Dec 29, 2016 at 5:18 PM, Peter Eisentraut wrote: > For additional entertainment, I include patches that integrate > background sessions into dblink. So dblink can open a connection to a > background session, and then you can use the existing dblink

Re: [HACKERS] background sessions

On Wed, Jan 4, 2017 at 2:57 PM, Andrew Borodin wrote: > 2017-01-04 10:23 GMT+05:00 amul sul : >> One more query, can we modify >> BackgroundSessionStart()/BackgroundSession struct to get background >> worker PID as well? > I think since session always has

Re: [HACKERS] background sessions

2017-01-04 10:23 GMT+05:00 amul sul : > One more query, can we modify > BackgroundSessionStart()/BackgroundSession struct to get background > worker PID as well? I think since session always has a PID it's absoultley reasonable to return PID. > I can understand this requirement

Re: [HACKERS] background sessions

On Tue, Jan 3, 2017 at 11:36 PM, Andrew Borodin wrote: > 2017-01-03 19:39 GMT+05:00 Peter Eisentraut > : >> >> On 1/3/17 1:26 AM, amul sul wrote: >> > One more requirement for pg_background is session, command_qh, >> > response_qh and

Re: [HACKERS] background sessions

2017-01-03 19:39 GMT+05:00 Peter Eisentraut : > On 1/3/17 1:26 AM, amul sul wrote: > > One more requirement for pg_background is session, command_qh, > > response_qh and worker_handle should be last longer than current > > memory context, for that we might need

Re: [HACKERS] background sessions

On 1/3/17 1:26 AM, amul sul wrote: > One more requirement for pg_background is session, command_qh, > response_qh and worker_handle should be last longer than current > memory context, for that we might need to allocate these in > TopMemoryContext. Please find attach patch does the same change in

Re: [HACKERS] background sessions

On Fri, Dec 30, 2016 at 3:48 AM, Peter Eisentraut wrote: > On 12/16/16 10:38 AM, Andrew Borodin wrote: >> 2016-12-16 20:17 GMT+05:00 Peter Eisentraut >> : And one more thing... Can we have BackgroundSessionExecute()

Re: [HACKERS] background sessions

On 12/16/16 10:38 AM, Andrew Borodin wrote: > 2016-12-16 20:17 GMT+05:00 Peter Eisentraut > : >>> And one more thing... Can we have BackgroundSessionExecute() splitted >>> into two parts: start query and wait for results? >>> It would allow pg_background to reuse

Re: [HACKERS] background sessions

2016-12-16 20:17 GMT+05:00 Peter Eisentraut : >> And one more thing... Can we have BackgroundSessionExecute() splitted >> into two parts: start query and wait for results? >> It would allow pg_background to reuse bgsession's code. > > Yes, I will look into that.

Re: [HACKERS] background sessions

On 12/15/16 1:54 AM, Andrew Borodin wrote: > And one more thing... Can we have BackgroundSessionExecute() splitted > into two parts: start query and wait for results? > It would allow pg_background to reuse bgsession's code. Yes, I will look into that. -- Peter Eisentraut

Re: [HACKERS] background sessions

On Thu, Dec 15, 2016 at 12:24 PM, Andrew Borodin wrote: > 2016-12-15 0:30 GMT+05:00 Peter Eisentraut : > TryBeginSession()? What exactly would that do? >>> Return status (success\failure) and session object, if a function

Re: [HACKERS] background sessions

2016-12-15 0:30 GMT+05:00 Peter Eisentraut : TryBeginSession()? >>> >>> What exactly would that do? >> Return status (success\failure) and session object, if a function succeeded. >> >> If there is max_connections exceeded, then (false,null). >> >> I'm not

Re: [HACKERS] background sessions

On 12/14/16 11:33 AM, Andrew Borodin wrote: > 2016-12-14 20:45 GMT+05:00 Peter Eisentraut > : >> On 12/11/16 5:38 AM, Andrew Borodin wrote: >>> 2. From my point of view the interface of the feature is the strong >>> point here (compared to pg_background). But it

Re: [HACKERS] background sessions

2016-12-14 20:45 GMT+05:00 Peter Eisentraut : > On 12/11/16 5:38 AM, Andrew Borodin wrote: >> 2. From my point of view the interface of the feature is the strong >> point here (compared to pg_background). But it does not help >> programmer to follow good practice:

Re: [HACKERS] background sessions

On 12/11/16 5:38 AM, Andrew Borodin wrote: > 2. From my point of view the interface of the feature is the strong > point here (compared to pg_background). But it does not help > programmer to follow good practice: bgworker is a valuable and limited > resource, may be we could start session with

Re: [HACKERS] background sessions

On 12/12/16 16:29, Robert Haas wrote: > On Mon, Dec 12, 2016 at 10:02 AM, Craig Ringer > wrote: >> On 12 Dec. 2016 21:55, "Robert Haas" wrote: >> On Sun, Dec 11, 2016 at 5:38 AM, Andrew Borodin >> wrote: >>> 1. As far as

Re: [HACKERS] background sessions

On 12 December 2016 at 23:29, Robert Haas wrote: > On Mon, Dec 12, 2016 at 10:02 AM, Craig Ringer > wrote: >> On 12 Dec. 2016 21:55, "Robert Haas" wrote: >> On Sun, Dec 11, 2016 at 5:38 AM, Andrew Borodin

Re: [HACKERS] background sessions

On Mon, Dec 12, 2016 at 10:02 AM, Craig Ringer wrote: > On 12 Dec. 2016 21:55, "Robert Haas" wrote: > On Sun, Dec 11, 2016 at 5:38 AM, Andrew Borodin > wrote: >> 1. As far as I can see, we connot use COPY FROM STDIN in

Re: [HACKERS] background sessions

On 12 Dec. 2016 21:55, "Robert Haas" wrote: On Sun, Dec 11, 2016 at 5:38 AM, Andrew Borodin wrote: > 1. As far as I can see, we connot use COPY FROM STDIN in bg session? > Since one of purposes is to orchestrate transactions, may be that > would be

Re: [HACKERS] background sessions

On Sun, Dec 11, 2016 at 5:38 AM, Andrew Borodin wrote: > 1. As far as I can see, we connot use COPY FROM STDIN in bg session? > Since one of purposes is to orchestrate transactions, may be that > would be valuable. A background worker has no client connection, so what would

Re: [HACKERS] background sessions

Hi! I'm planning to review this patch. I have some questions, maybe answers could help me understand patch better. 1. As far as I can see, we connot use COPY FROM STDIN in bg session? Since one of purposes is to orchestrate transactions, may be that would be valuable. 2. From my point of view the

Re: [HACKERS] background sessions

On Tue, Nov 1, 2016 at 2:25 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > Here is a patch for the background sessions C API and PL/Python support. > This was previously submitted as "autonomous transactions", which > proved controversial, and there have been several

[HACKERS] background sessions

Here is a patch for the background sessions C API and PL/Python support. This was previously submitted as "autonomous transactions", which proved controversial, and there have been several suggestions for a new name. I have renamed everything, removed all the incomplete PL/pgSQL stuff, did some