Thread: Unable to find the details of bug fix in 9.6.x minor version.

On 6/3/20 2:32 AM, Sameer Malve wrote:
> Hi Team,
> 
> I am seeing in postgresql release notes that below bugs are fix in 9.6.x 
> version but unable to find the details for about that bug .

Easiest way I found is to go here:

https://git.postgresql.org/gitweb/?p=postgresql.git

Then go to the tags section and select the tag for the release. So for 
the the first item below:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=518d5492911d445b126e9d5c669a83b5cae43e50

Then click on Log and search for wal_sender_timeout. That leads you to:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=518d5492911d445b126e9d5c669a83b5cae43e50

"Ignore server-side delays when enforcing wal_sender_timeout.

Healthy clients of servers having poor I/O performance, such as
buildfarm members hamster and tern, saw unexpected timeouts.  That
disagreed with documentation.  This fix adds one gettimeofday() call
whenever ProcessRepliesIfAny() finds no client reply messages.
Back-patch to 9.4; the bug's symptom is rare and mild, and the code all
moved between 9.3 and 9.4.

Discussion: https://postgr.es/m/20180826034600.GA1105084@rfd.leadboat.com"


> 
> _Fixed in 9.6.11_
> _
> _
> Fix unexpected timeouts when using wal_sender_timeout on a slow server 
> (Noah Misch) .
> 
> _Fixed in 9.6.12_
> _
> _
> 1. A new server parameter data_sync_retry has been added to control 
> this; if you are certain that your kernel does not discard dirty data 
> buffers in such scenarios, you can set data_sync_retry to on to restore 
> the old behavior._
> _
> 2. Fix logic for stopping a subset of WAL senders when synchronous 
> replication is enabled
> 3. Make the archiver prioritize WAL history files over WAL data files 
> while choosing which file to archive next
> 
> _Fixed in 9.6.16_
> _
> _
> Ensure that temporary WAL and history files are removed at the end of 
> archive recovery.
> 
> Avoid unwanted delay during shutdown of a logical replication walsender. _
> _
> 
> _Fixed in 9.6.17_
> 
> Fix failure in logical replication publisher after a database crash and 
> restart
> 
> _Fixed in 9.6.18:_
> _
> _
> This can eliminate many attempts to fetch non-existent WAL files from 
> archive storage, which is helpful if archive access is slow._
> _
> 
> Regards,
> Sameer Malve


-- 
Adrian Klaver
adrian.klaver@aklaver.com

Sameer Malve <malvesameer@gmail.com> writes:
> I am seeing in postgresql release notes that below bugs are fix in 9.6.x
> version but unable to find the details for about that bug .

If you want more detail than is in the release notes, look at the SGML
source for the notes to see the commit references, for example

    <listitem>
<!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [ab0ed6153] 2018-08-31 22:59:58 -0700
Branch: REL_11_STABLE Release: REL_11_0 [ee0ab2754] 2018-08-31 23:00:01 -0700
Branch: REL_10_STABLE [1664c8b30] 2018-08-31 23:00:01 -0700
Branch: REL9_6_STABLE [081e4104a] 2018-08-31 23:00:02 -0700
Branch: REL9_5_STABLE [e3eca937c] 2018-08-31 23:00:02 -0700
Branch: REL9_4_STABLE [20cd88857] 2018-08-31 23:00:03 -0700
-->
     <para>
      Fix unexpected timeouts when
      using <varname>wal_sender_timeout</varname> on a slow server
      (Noah Misch)
     </para>
    </listitem>

and then you can look at, eg,

https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=081e4104a

(or do "git show 081e4104a" in a git checkout) to see the commit log
message and the actual code changes.

For the last year or so, the policy has been to include these commit
reference comments in every relevant branch's release-m.n.sgml file.
Before that you had to dig around a little, because in the interests
of space I only included them in the newest released branch.  (So for
example the above is from the v10 branch; v11 was not yet released
so it had no release note for this.)

As Adrian mentions, grepping the result of "git log" is also a
good way to find relevant commits.

            regards, tom lane