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
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
@@ -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
- 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)
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.
+ 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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: