Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Sure. If you have an idea what the right thing to do is, please go
> > ahead.
>
> Yeah, I'll modify the patch and commit sometime later today.
>
> > I actually don't have a clear idea what's going on here. I
> > guess it's that the wait_for_stats() guarantees that the stats message
> > from the index insertion has been received but the status messages
> > from the "trunc" tables might not have gotten there yet.
>
> That's what it looks like to me. I now think that the apparent
> connection to parallel query is a mirage. The reason we've only
> seen a few cases so far is that the flapping test is new: it
> wad added in commit d42358efb16cc811, on 20 Feb. If we left it
> as-is, I think we'd eventually see the same failure without forcing
> parallel mode. In fact, that's pretty much what you describe below,
> isn't it? The pg_sleep is sort of half-bakedly substituting for
> a proper wait.
It was added on Feb 20 all right, but of *last year*. It's been there
working happily for a year now.
The reason I added the trunc test in the middle of the index update
tests is that I dislike tests that sleep for long without real purpose;
it seems pretty reasonable to me to have both sleeps actually be the
same wait.
Instead of adding another sleep function, another possibility is to add
two booleans, one for the index counter and another for the truncate
counters, and only terminate the sleep if both are true. I don't see
any reason to make this test any slower than it already is.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services