> On 2 Sep 2022, at 10:00, Michael Paquier wrote:
>
> On Fri, Aug 26, 2022 at 09:51:26AM +0900, Michael Paquier wrote:
>> Fine by me if both you and Daniel want to be more careful with this
>> change. We could always argue about a backpatch later if there is
>> more ask for it, as well.
>
> Dan
> On 2 Sep 2022, at 10:00, Michael Paquier wrote:
>
> On Fri, Aug 26, 2022 at 09:51:26AM +0900, Michael Paquier wrote:
>> Fine by me if both you and Daniel want to be more careful with this
>> change. We could always argue about a backpatch later if there is
>> more ask for it, as well.
>
> Dan
On Fri, Aug 26, 2022 at 09:51:26AM +0900, Michael Paquier wrote:
> Fine by me if both you and Daniel want to be more careful with this
> change. We could always argue about a backpatch later if there is
> more ask for it, as well.
Daniel, are you planning to apply this one on HEAD?
--
Michael
s
Re: Daniel Gustafsson
> The attached adds the Exit Status section to pg_recvlogical docs which is
> present in pg_receivewal to make them more aligned, and tweaks comments to
> pgindent standards. This is the version I think is ready to commit.
Looks good to me.
Thanks,
Christoph
On Thu, Aug 25, 2022 at 08:45:05PM +0200, Magnus Hagander wrote:
> I'm leaning towards considering it a feature-change and thus not
> something to backpatch (I'd be OK sneaking it into 15 though, as that
> one is not released yet and it feels like a perfectly *safe* change).
> Not enough to insist
On Thu, Aug 25, 2022 at 5:13 PM Christoph Berg wrote:
>
> Re: Michael Paquier
> > FWIW, I've worked on an archiver integration a few years ago and got
> > annoyed that we use SIGINT while SIGTERM was the default (systemd was
> > not directly used there but the signal problem was the same, so we ha
Re: Michael Paquier
> FWIW, I've worked on an archiver integration a few years ago and got
> annoyed that we use SIGINT while SIGTERM was the default (systemd was
> not directly used there but the signal problem was the same, so we had
> to go through some loops to make the stop signal configurable
On Thu, Aug 25, 2022 at 11:19:05AM +0200, Daniel Gustafsson wrote:
> I think this can be argued both for and against backpatching. Catching
> SIGTERM
> makes a lot of sense, especially given systemd's behavior. On the other hand,
> This adds functionality to something arguably working as intende
> On 23 Aug 2022, at 02:15, Michael Paquier wrote:
>
> On Mon, Aug 22, 2022 at 04:05:16PM +0200, Christoph Berg wrote:
>> Do you mean it can, or can not be backpatched? (I'd argue for
>> backpatching since the behaviour is slightly broken at the moment.)
>
> I mean that it is fine to backpatch t
On Mon, Aug 22, 2022 at 04:05:16PM +0200, Christoph Berg wrote:
> Do you mean it can, or can not be backpatched? (I'd argue for
> backpatching since the behaviour is slightly broken at the moment.)
I mean that it is fine to backpatch that, in my opinion.
--
Michael
signature.asc
Description: PGP
Re: Michael Paquier
> While looking at the last patch proposed, it strikes me that
> time_to_stop should be sig_atomic_t in pg_receivewal.c, as the safe
> type of variable to set in a signal handler. We could change that,
> while on it..
Done in the attached patch.
> Backpatching this stuff is n
On Fri, Aug 19, 2022 at 05:34:56PM +0530, Bharath Rupireddy wrote:
> +1 to add "some" info in the docs (I'm not sure about the better
> wording though), we can try to be more specific of the use case if
> required.
Yes, the amount of extra docs provided by the patch proposed by
Christoph looks fin
On Fri, Aug 19, 2022 at 4:24 PM Christoph Berg wrote:
>
> Re: Bharath Rupireddy
> > pg_receivewal will exit with status 0 when
> > - terminated by the SIGINT signal. (That is the
> > + terminated by the SIGINT or
> > + SIGTERM signal. (That is the
> > normal way to end it. Hence i
Re: Bharath Rupireddy
> pg_receivewal will exit with status 0 when
> - terminated by the SIGINT signal. (That is the
> + terminated by the SIGINT or
> + SIGTERM signal. (That is the
> normal way to end it. Hence it is not an error.) For fatal errors or
> other signals, the exi
On Tue, Aug 16, 2022 at 7:26 PM Christoph Berg wrote:
>
> Re: Bharath Rupireddy
> > Don't we need a similar explanation [1] for pg_recvlogical docs?
> >
> > [1]
> >
> > In the absence of fatal errors, pg_receivewal
> > - will run until terminated by the SIGINT signal
> > - ( > action="
Re: Bharath Rupireddy
> Don't we need a similar explanation [1] for pg_recvlogical docs?
>
> [1]
>
> In the absence of fatal errors, pg_receivewal
> - will run until terminated by the SIGINT signal
> - ( action="simul">ControlC).
> + will run until terminated by the SIGINT
> + ( ac
On Tue, Aug 16, 2022 at 5:15 PM Daniel Gustafsson wrote:
>
> > On 16 Aug 2022, at 13:36, Christoph Berg wrote:
>
> >> pqsignal(SIGINT, sigint_handler);
> >> +pqsignal(SIGTERM, sigint_handler);
> >> Tiny nitpick, I think we should rename sigint_handler to just sig_handler
> >> as it
> >>
> On 16 Aug 2022, at 13:36, Christoph Berg wrote:
>> pqsignal(SIGINT, sigint_handler);
>> +pqsignal(SIGTERM, sigint_handler);
>> Tiny nitpick, I think we should rename sigint_handler to just sig_handler as
>> it
>> does handle more than sigint.
>
> I went with sigexit_handler since pg_
Re: Daniel Gustafsson
> In general that's a good idea, but they are so trivial that I don't really see
> much point in doing that in this particular case.
Plus the variable they set is called differently...
Christoph
> On 16 Aug 2022, at 13:40, Bharath Rupireddy
> wrote:
>
> On Tue, Aug 16, 2022 at 5:06 PM Christoph Berg wrote:
>> I went with sigexit_handler since pg_recvlogical has also a
>> sighup_handler and "sig_handler" would be confusing there.
>
> Can we move these signal handlers to streamutil.h/.
On Tue, Aug 16, 2022 at 5:06 PM Christoph Berg wrote:
>
> Re: Daniel Gustafsson
> > Do you think pg_recvlogical should support SIGTERM as well? (The signals
> > which
> > it does trap should be added to the documentation which just now says "until
> > terminated by a signal" but that's a separat
Re: Daniel Gustafsson
> Do you think pg_recvlogical should support SIGTERM as well? (The signals
> which
> it does trap should be added to the documentation which just now says "until
> terminated by a signal" but that's a separate thing.)
Ack, that makes sense, added in the attached updated pat
> On 15 Aug 2022, at 14:45, Christoph Berg wrote:
> The problem was that systemd's default KillSignal is SIGTERM, while
> pg_receivewal flushes the output compression buffers on SIGINT only.
Supporting SIGTERM here makes sense, especially given how systemd works.
> The attached patch makes it d
23 matches
Mail list logo
