Handle a race condition between portal close 'C' message and new request for

running the portal, as part of the next step of query execution

A producer will unbind and remove the SharedQ once all consumers are done
with reading pending data. It does not wait for consumers to actually send
close 'C' message. If the next step of the execution now recreates the SharedQ
with the same name (because its the same RemoteSubplan being re-executed), and
if the close messages arrives after that, but before the new producer gets
chance to bind to the SharedQ, we will end up marking future consumers of the
new SharedQ as 'DONE'. The SharedQueueAcquire then incorrectly assumes that
this is a stale Q belonging to earlier execution and gets in an infinite wait.

Also do not try indefinitely for the old producer to unbind and remove a stale
queue. Any further bugs in this area will cause infinite loops. Instead try for
a fixed number of times and then let the query fail.

0 files changed, 0 insertions, 0 deletions