On Wed, Jun 10, 2020 at 8:14 PM Kyle Kingsbury <aphyr@jepsen.io> wrote:
> I wanted to let you know that I've put together a draft of a report on these
> findings, and if you've got any comments you'd like to offer, I'd be happy to
> hear them, either on-list or privately.
> http://jepsen.io/analyses/postgresql-12.3?draft-token=Kets1Quayfs
You should mention that a fix was committed this morning:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5940ffb221316ab73e6fdc780dfe9a07d4221ebb
You may want to draw attention to the isolation test, since it's a
perfect distillation of the bug. I'm certain that it cannot be
simplified any further.
Note that the test involves three transactions/sessions -- not two.
Elle always complained about a pair of transactions that had a cycle,
which were similar to the "foo" and "bar" sessions from the test. But
Elle never said anything about a third transaction (that played the
role of the "trouble" transaction from the test). Of course, this
makes perfect sense -- the third/"trouble" transaction *should* be
totally irrelevant. Note that the UPDATE has to come from a third
session/transaction for things to go awry. And note that the order of
each statement has to match the order from the isolation test. For
example, no problems occur if you flip the order of "trouble_update"
and "bar_select" -- because that would mean that the physical tuple
does not get physically updated before being examined by "bar_select".
You should also specifically mention that the next upcoming minor
release will be on August 13th, 2020:
https://www.postgresql.org/developer/roadmap/
Users that are concerned about this bug will be able to get a new
minor release with the fix by that date, at the latest.
Thanks
--
Peter Geoghegan
