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

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Sameer Malve <malvesameer(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Unable to find the details of bug fix in 9.6.x minor version.
Date: 2020-06-03 13:47:19
Message-ID: 7d570f68-39ea-3715-978d-0885f3c5fbc8@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jeremy Schneider 2020-06-03 13:59:16 Re: select count(id) on RDS replica causing high CPU load on RDS master
Previous Message Julien Rouhaud 2020-06-03 12:42:20 Re: Replication conflicts despite hot_standby_feedback = on?