On 06/05/17 17:25, Tom Lane wrote:
> Petr Jelinek <petr.jeli...@2ndquadrant.com> writes:
>> Hmm, the 2bef06d51 and 56e19d938 are fixes for different bugs, we can
>> keep them together since result of both is corrupted snapshot, but the
>> description can't just mangle pieces of text from different commits
>> together like this as that's misleading.
> 
> OK, can you suggest better wording?
> 

Something like the attached (it requires some polishing of English
probably).

-- 
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/doc/src/sgml/release-9.6.sgml b/doc/src/sgml/release-9.6.sgml
index cdff084..195cbb1 100644
--- a/doc/src/sgml/release-9.6.sgml
+++ b/doc/src/sgml/release-9.6.sgml
@@ -92,17 +92,24 @@ Branch: REL9_5_STABLE [54270d7eb] 2017-04-27 15:29:43 -0700
 Branch: REL9_4_STABLE [b6ecf26cc] 2017-04-27 15:29:52 -0700
 -->
      <para>
-      Fix possibly-corrupt initial snapshot during logical decoding
-      (Petr Jelinek, Andres Freund)
+      Fix two bugs resulting in possibly-corrupt initial exported snapshot
+      during logical decoding (Petr Jelinek, Andres Freund)
      </para>
 
      <para>
       If a logical decoding replication slot was created while another slot
-      already exists, it was initialized with a potentially-corrupted
-      snapshot, allowing wrong data to be returned during decoding.
-      The time window during which this snapshot continued to be used
-      depended on how busy the server was; under low load it would be hard
-      to see any problem.
+      already exists, it would exported a potentially-corrupted snapshot,
+      allowing wrong data to be returned when such snapshot was imported to
+      another backend.
+     </para>
+
+     <para>
+      Logical decoding normally preserves all required historical catalog
+      tuples, it didn't guarantee that the non-catalog tuples also
+      were preserved for exported snapshot. This could have resulted in
+      concurrent VACUUM or HOT pruning to remove tuples needed by the
+      snapshot. The time window for this was very small and the problem
+      required server to be very busy during slot creation.
      </para>
     </listitem>
 
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to