On Wed, Jan 24, 2018 at 7:39 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> This started crashing some time yesterday with an assertion failure in
> the isolation tests after commit 2badb5af landed. Reordering of code
> in parallel.c confused patch's fuzz heuristics leading
> SetSerializableXact() to be called too soon. Here's a fix for that.
I took a look at this today and thought it might be OK to commit,
modulo a few minor issues: (1) you didn't document the new tranche and
(2) I prefer to avoid if (blah) { Assert(thing) } in favor of
Assert(!blah || thing).
But then I got a little bit concerned about ReleasePredicateLocks().
Suppose that in the middle of a read-only transaction,
SXACT_FLAG_RO_SAFE becomes true. The next call to
SerializationNeededForRead in each process will call
ReleasePredicateLocks. In the workers, this won't do anything, so
we'll just keep coming back there. But in the leader, we'll go ahead
do all that stuff, including MySerializableXact =
InvalidSerializableXact. But in the workers, it's still set. Maybe
that's OK, but I'm not sure that it's OK...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
