Thread: BUG #17073: docs - "Improve signal handling reliability"
The following bug has been logged on the website: Bug reference: 17073 Logged by: Andrey Lizenko Email address: lizenko79@gmail.com PostgreSQL version: 14beta2 Operating system: any Description: Looks like description was missed or corrupted for the following release note: https://www.postgresql.org/docs/14/release-14.html Improve signal handling reliability (Fujii Masao) GENERAL ENOUGH?
On Fri, Jun 25, 2021 at 02:11:57AM +0000, PG Bug reporting form wrote: > The following bug has been logged on the website: > > Bug reference: 17073 > Logged by: Andrey Lizenko > Email address: lizenko79@gmail.com > PostgreSQL version: 14beta2 > Operating system: any > Description: > > Looks like description was missed or corrupted for the following release > note: > https://www.postgresql.org/docs/14/release-14.html > > Improve signal handling reliability (Fujii Masao) > GENERAL ENOUGH? It means I am not clear if this text is accurate or needs improvement. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
On 2021/06/29 10:02, Bruce Momjian wrote: > On Fri, Jun 25, 2021 at 02:11:57AM +0000, PG Bug reporting form wrote: >> The following bug has been logged on the website: >> >> Bug reference: 17073 >> Logged by: Andrey Lizenko >> Email address: lizenko79@gmail.com >> PostgreSQL version: 14beta2 >> Operating system: any >> Description: >> >> Looks like description was missed or corrupted for the following release >> note: >> https://www.postgresql.org/docs/14/release-14.html >> >> Improve signal handling reliability (Fujii Masao) >> GENERAL ENOUGH? > > It means I am not clear if this text is accurate or needs improvement. Since this explains the commit 2945a488a, it's better to describe something like the following? Make the standby handle signal promptly. Previously there was the case where the standby could not promptly handle the signal like shutdown request received while waiting on wal_retrieve_retry_interval. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
On Wed, Jun 30, 2021 at 5:54 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
On 2021/06/29 10:02, Bruce Momjian wrote:
> On Fri, Jun 25, 2021 at 02:11:57AM +0000, PG Bug reporting form wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 17073
>> Logged by: Andrey Lizenko
>> Email address: lizenko79@gmail.com
>> PostgreSQL version: 14beta2
>> Operating system: any
>> Description:
>>
>> Looks like description was missed or corrupted for the following release
>> note:
>> https://www.postgresql.org/docs/14/release-14.html
>>
>> Improve signal handling reliability (Fujii Masao)
>> GENERAL ENOUGH?
>
> It means I am not clear if this text is accurate or needs improvement.
Since this explains the commit 2945a488a, it's better to describe
something like the following?
Make the standby handle signal promptly.
Previously there was the case where the standby could not promptly
handle the signal like shutdown request received while waiting on
wal_retrieve_retry_interval.
The wording still needs some work...but is this even release note worthy?
We forget to check for interrupts before sleeping in an otherwise busy-wait loop. We corrected the oversight.
Otherwise, "The standby startup process now promptly handles interrupts."
Most of what I'm reading says this only impacted the startup of the standby process; normal operations already worked correctly. Is that correct?
David J.
On 2021/07/01 10:17, David G. Johnston wrote: > On Wed, Jun 30, 2021 at 5:54 PM Fujii Masao <masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com>> wrote: > > On 2021/06/29 10:02, Bruce Momjian wrote: > > On Fri, Jun 25, 2021 at 02:11:57AM +0000, PG Bug reporting form wrote: > >> The following bug has been logged on the website: > >> > >> Bug reference: 17073 > >> Logged by: Andrey Lizenko > >> Email address: lizenko79@gmail.com <mailto:lizenko79@gmail.com> > >> PostgreSQL version: 14beta2 > >> Operating system: any > >> Description: > >> > >> Looks like description was missed or corrupted for the following release > >> note: > >> https://www.postgresql.org/docs/14/release-14.html <https://www.postgresql.org/docs/14/release-14.html> > >> > >> Improve signal handling reliability (Fujii Masao) > >> GENERAL ENOUGH? > > > > It means I am not clear if this text is accurate or needs improvement. > > Since this explains the commit 2945a488a, it's better to describe > something like the following? > > Make the standby handle signal promptly. > > Previously there was the case where the standby could not promptly > handle the signal like shutdown request received while waiting on > wal_retrieve_retry_interval. > > > The wording still needs some work...but is this even release note worthy? This change is not so user-visible, so I have no strong opinion about whether to list this in the release note. > We forget to check for interrupts before sleeping in an otherwise busy-wait loop. We corrected the oversight. > > Otherwise, "The standby startup process now promptly handles interrupts." > > Most of what I'm reading says this only impacted the startup of the standby process; normal operations already worked correctly. Is that correct? Yes, you're right. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
On 2021-Jun-30, David G. Johnston wrote: > On Wed, Jun 30, 2021 at 5:54 PM Fujii Masao <masao.fujii@oss.nttdata.com> > wrote: > > Since this explains the commit 2945a488a, it's better to describe > > something like the following? > The wording still needs some work...but is this even release note worthy? > > We forget to check for interrupts before sleeping in an otherwise busy-wait > loop. We corrected the oversight. Yeah, it's a good question. I wonder if this should be back-patched, so it'd be noted as a bugfix in the next set of minors rather than as a new feature for 14. (It's not a busy-wait loop, just a sleep, unless I misunderstand.) > Most of what I'm reading says this only impacted the startup of the standby > process; normal operations already worked correctly. Is that correct? Yes, because the change is in WaitForWALToBecomeAvailable(). -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "Right now the sectors on the hard disk run clockwise, but I heard a rumor that you can squeeze 0.2% more throughput by running them counterclockwise. It's worth the effort. Recommended." (Gerry Pourwelle)
On 2021/07/01 10:57, Alvaro Herrera wrote: > On 2021-Jun-30, David G. Johnston wrote: > >> On Wed, Jun 30, 2021 at 5:54 PM Fujii Masao <masao.fujii@oss.nttdata.com> >> wrote: > >>> Since this explains the commit 2945a488a, it's better to describe >>> something like the following? > >> The wording still needs some work...but is this even release note worthy? >> >> We forget to check for interrupts before sleeping in an otherwise busy-wait >> loop. We corrected the oversight. > > Yeah, it's a good question. I wonder if this should be back-patched, so > it'd be noted as a bugfix in the next set of minors rather than as a new > feature for 14. Yes. I'm not sure why I did not back-patch the change, but IMO it's worth doing that. Barring any objection, I will do that. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
On Wednesday, June 30, 2021, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
On 2021-Jun-30, David G. Johnston wrote:
> We forget to check for interrupts before sleeping in an otherwise busy-wait
> loop. We corrected the oversight.
(It's not a busy-wait loop, just a sleep, unless I misunderstand.)
I was just repeating the code comment:
| * and retry from the archive, but if it hasn't been long | ||
| * since last attempt, sleep wal_retrieve_retry_interval | ||
| * milliseconds to avoid busy-waiting. |
Which is why I went with “an otherwise busy-wait loop” as a rephrasing of “avoid busy-waiting”.
I concur that this seems back-patch worthy.
David J.
On 2021/07/01 11:41, Fujii Masao wrote: > > Yes. I'm not sure why I did not back-patch the change, but IMO it's worth doing that. > Barring any objection, I will do that. I did back-patch to all supported versions. Thanks! So we can remove the item "Improve signal handling reliability" from the release note for v14. Patch attached. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION