Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We still seem to have occasional problems with dropdb while running
> contrib installcheck. The symptoms look like this:
I see this regularly on some platforms, and seldom/never on others.
I've also seen it happen when scripting a tight loop around the
core regression tests.
I think it must be related to details of the kernel scheduler's
behavior. Some schedulers will let the exiting backend have cycles
right about then, and some won't. (IIRC, I've confirmed by strace'ing
that when this happens, the exiting backend has in fact been granted
*no* cycles between when the old psql quits and when the new backend
gets to the point of failing the dropdb. I suppose there's some sort
of foreground/background priority heuristic involved.)
> I guess we could put a small sleep before dropdb in pg_regress.sh to
I'd prefer to put it in contrib/Makefile's installcheck rule, so that
we don't pay the price in contexts where it's not needed.
A more radical solution would be to tweak libpq's PQfinish() to be a
synchronous close, ie, wait for the backend to exit before returning.
I think we've speculated about doing that in the past, but never been
fully convinced that it's worth the downside of usually-unnecessary
client delay.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
