Re: Unable to find the details of bug fix in 9.6.x minor version. - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Unable to find the details of bug fix in 9.6.x minor version.
Date
Msg-id 7d570f68-39ea-3715-978d-0885f3c5fbc8@aklaver.com
Whole thread Raw
In response to Unable to find the details of bug fix in 9.6.x minor version.  (Sameer Malve <malvesameer@gmail.com>)
List pgsql-general
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



pgsql-general by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Replication conflicts despite hot_standby_feedback = on?
Next
From: Jeremy Schneider
Date:
Subject: Re: select count(id) on RDS replica causing high CPU load on RDSmaster