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, Rem
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 that launched it.
>>> If an error occurs while output is
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 happen.
>> I think it would be b
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 changed.
>
> Some review
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:
+pq_redirect_to_shm_mq(sess
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
> >> independent of anything this patch does. It wou
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
>> background process not doing
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 to be hard to arrange, and I think it isn't
> nece
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 to arrange for the worker t
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. will be background session process closed automatically when parent
> >> > process is
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 is closed?
>>
>> If the communications queue goes away the p
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.
> This is similar to how a backend proc
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 mor
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 functions
> > to send queries, read result
> 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 g
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
>>> background sessions into dblink. So dblink can open a connection to a
>>> ba
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, and then you can use the existing
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 functions
> to send queries, read result
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 a PID it's absoultley reasonable to return
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 could be sound usel
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 worker_handle should be last longer than current
>> > memory co
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 to allocate these in
> > TopMemoryCo
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
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() splitted
into two parts: start query and wait for results?
It woul
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 bgsession's code.
>>
>> Yes, I wil
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.
Thank you. I'm marking both patches
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 http://www
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 succeeded.
>>>
>>> If there is max_connections exceeded, then
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 sure whether this idiom is common for
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 does not help
>>> programmer to fol
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: bgworker is a valuable and limited
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 som
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 I can see, we connot use COPY FROM STDIN in bg session?
>>> Since one of pu
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
>> wrote:
>>> 1. As far as I can see, we connot use COPY FROM STDIN in bg session?
>>> Sin
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 bg session?
>> Since one of purposes is to orchestrate transactions, may be t
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 valuable.
A background worker has no client co
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 COPY FROM STDIN do?
-
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
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 suggestion
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 r
40 matches
Mail list logo