On Thu, Jul 16, 2020 at 8:44 PM Robert Haas wrote:
>
> On Wed, Jul 15, 2020 at 11:51 AM Andres Freund wrote:
> > Indeed looks like a typo. Robert, do you concur?
>
> Yes, that's definitely unintentional. Oops.
>
Pushed the fix.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprised
On Wed, Jul 15, 2020 at 11:51 AM Andres Freund wrote:
> Indeed looks like a typo. Robert, do you concur?
Yes, that's definitely unintentional. Oops.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi,
On 2020-07-15 20:33:59 +0530, Bharath Rupireddy wrote:
> >
> > +1. I will commit this tomorrow unless someone thinks otherwise.
> >
>
> I think versions <= 12, have "pqsignal(SIGHUP,
> logicalrep_launcher_sighup)", not sure why and which commit removed
> logicalrep_launcher_sighup().
commit
>
> +1. I will commit this tomorrow unless someone thinks otherwise.
>
I think versions <= 12, have "pqsignal(SIGHUP,
logicalrep_launcher_sighup)", not sure why and which commit removed
logicalrep_launcher_sighup().
We might have to also backpatch this patch to version 13.
With Regards,
Bharath
On Wed, Jul 15, 2020 at 6:21 PM Dilip Kumar wrote:
>
> On Wed, Jul 15, 2020 at 6:17 PM Bharath Rupireddy
> wrote:
> >
> > Hi,
> >
> > In ApplyLauncherMain, it seems like we are having SIGTERM signal
> > mapped for config reload. I think we should be having SIGHUP for
> > SignalHandlerForConfigRel
On Wed, Jul 15, 2020 at 6:17 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> In ApplyLauncherMain, it seems like we are having SIGTERM signal
> mapped for config reload. I think we should be having SIGHUP for
> SignalHandlerForConfigReload(). Otherwise we miss to take the updated
> value for wal_retrieve_
