> On 14 Sep 2022, at 17:37, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> On 14 Sep 2022, at 17:06, Tom Lane wrote:
>>> barring objection,
>>> I'm going to run around and fix those.
>
>> No objections, unless you have better things to do and wan't me to clean up
>> then I'll take care of it
Daniel Gustafsson writes:
> On 14 Sep 2022, at 17:06, Tom Lane wrote:
>> barring objection,
>> I'm going to run around and fix those.
> No objections, unless you have better things to do and wan't me to clean up
> then I'll take care of it.
Nah, not your bug. There are a bunch of these, I'm fi
> On 14 Sep 2022, at 17:06, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Since pg_recvlogical is also supposed to run as a daemon, teach it about
>> SIGTERM as well and update the documentation to match. While in there,
>> change pg_receivewal's time_to_stop to be sig_atomic_t like it is in
Daniel Gustafsson writes:
> Since pg_recvlogical is also supposed to run as a daemon, teach it about
> SIGTERM as well and update the documentation to match. While in there,
> change pg_receivewal's time_to_stop to be sig_atomic_t like it is in
> pg_recvlogical.
While looking at this commit, I w
Handle SIGTERM in pg_receivewal and pg_recvlogical
In pg_receivewal, compressed output is only flushed on clean exits. The
reason to support SIGTERM as well as SIGINT (which is currently handled)
is that pg_receivewal might well be running as a daemon, and systemd's
default KillSignal is SIGTERM.
