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
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
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.
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?
>
On Wed, Aug 5, 2015 at 3:33 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com 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
On Wed, Aug 5, 2015 at 2:07 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 7, 2015 at 4:34 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
With that notion of backend, to fix the original problem I reported,
PostmasterMarkPIDForWorkerNotify() should also look at the
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 Tue, Jul 7, 2015 at 4:34 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com 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
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
On Thu, Jun 4, 2015 at 8:52 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com 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
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
11 matches
Mail list logo