On Wed, Sep 9, 2015 at 8:14 AM, Ashutosh Bapat
wrote:
> PFA patch with improved test module and fix for a bug.
>
> bgworker_sigusr1_handler() should set the latch when set_latch_on_sigusr1 is
> true, similar to procsignal_sigusr1_handler(). Without this fix, if a
> background worker without DATABA
On Wed, Sep 2, 2015 at 2:02 AM, Robert Haas wrote:
> On Mon, Aug 31, 2015 at 8:01 AM, Ashutosh Bapat
> wrote:
> >> Thanks. It needs testing though to see if it really works as
> >> intended. Can you look into that?
> >
> > PFA the patch containing your code changes + test module. See if that
>
On Mon, Aug 31, 2015 at 8:01 AM, Ashutosh Bapat
wrote:
>> Thanks. It needs testing though to see if it really works as
>> intended. Can you look into that?
>
> PFA the patch containing your code changes + test module. See if that meets
> your expectations.
Thanks. I don't think this test modul
On Sat, Aug 8, 2015 at 7:46 PM, Robert Haas wrote:
> On Wed, Aug 5, 2015 at 3:33 AM, Ashutosh Bapat
> wrote:
> > This idea looks good.
>
> Thanks. It needs testing though to see if it really works as
> intended. Can you look into that?
>
PFA the patch containing your code changes + test modul
On Wed, Aug 5, 2015 at 3:33 AM, Ashutosh Bapat
wrote:
> This idea looks good.
Thanks. It needs testing though to see if it really works as
intended. Can you look into that?
> Looking at larger picture, we should also enable this feature to be used by
> auxilliary processes. It's very hard to a
Ashutosh Bapat wrote:
> Looking at larger picture, we should also enable this feature to be
> used by auxilliary processes. It's very hard to add a new auxilliary
> process in current code. One has to go add code at many places to
> make sure that the auxilliary processes die and are re-started
>
On Wed, Aug 5, 2015 at 2:07 AM, Robert Haas wrote:
> On Tue, Jul 7, 2015 at 4:34 AM, Ashutosh Bapat
> wrote:
> > With that notion of backend, to fix the original problem I reported,
> > PostmasterMarkPIDForWorkerNotify() should also look at the
> > BackgroundWorkerList. As per the comments in th
On Tue, Jul 7, 2015 at 4:34 AM, Ashutosh Bapat
wrote:
> With that notion of backend, to fix the original problem I reported,
> PostmasterMarkPIDForWorkerNotify() should also look at the
> BackgroundWorkerList. As per the comments in the prologue of this function,
> it assumes that only backends ne
In CleanupBackgroundWorker(), we seem to differentiate between a background
worker with shared memory access and a backend.
2914 /*
2915 * Additionally, for shared-memory-connected workers, just
like a
2916 * backend, any exit status other than 0 or 1 is considered a
cras
On Mon, Jun 8, 2015 at 1:51 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>
>> After studying this, I think it's a bug. See this comment:
>>
>> * Normal child backends can only be launched when we are in PM_RUN or
>> * PM_HOT_STANDBY state. (We also allow launch of normal
>> * child backends
Robert Haas wrote:
> After studying this, I think it's a bug. See this comment:
>
> * Normal child backends can only be launched when we are in PM_RUN or
> * PM_HOT_STANDBY state. (We also allow launch of normal
> * child backends in PM_WAIT_BACKUP state, but only for superusers.)
> * In ot
On Thu, Jun 4, 2015 at 8:52 AM, Ashutosh Bapat
wrote:
> Documentation here http://www.postgresql.org/docs/devel/static/bgworker.html
> does not indicate any relation between the fields bgw_notify_pid and
> bgw_flags of BackgroundWorker structure. But in one has to set
> BGWORKER_BACKEND_DATABASE_C
Hi,
Documentation here http://www.postgresql.org/docs/devel/static/bgworker.html
does not indicate any relation between the fields bgw_notify_pid and
bgw_flags of BackgroundWorker structure. But in one has to set
BGWORKER_BACKEND_DATABASE_CONNECTION in order to use bgw_notify_pid feature.
In Backg
13 matches
Mail list logo
