Skip to content

Conversation

@silent-observer
Copy link
Collaborator

@silent-observer silent-observer commented Oct 28, 2025

Previously ShareInputScans could not be used inside InitPlans due to synchronization issues. This happened because InitPlans are executed sequentially: they are separate queries dispatched to QEs, and each query has to complete before the next one is started.

This conflicts with ShareInputScan execution (in cross-slice case), which assumes that producer and consumer slices are both available at the same time, so producer must notify consumers through shared when it's done preparing the tuplestore, and the consumers must notify the producer when they're done reading it, so it's okay to producer to delete the tuplestore.

Synchronization is actually rather hard, since InitPlans can contain several ShareInputScans, which must be synchronized normally. So the producer must still wait for all the consumers in the same InitPlan, but not for consumers in other InitPlans, and not for consumers in the main plan. Similarly, only the consumers in the same InitPlan must wait for the producer. For that we must somehow determine

  1. whether the producer is in an InitPlan
  2. which consumers are in the same InitPlan
  3. count how many of them there are, so that the producer waits for the reduced number of consumers (or none at all).

Cleanup is harder to deal with, since producer has to clean up the tuplestore after the consumers are done, which is after producer's InitPlan is completed and its transaction commited. This means we must store the tuplestore in some separate global place that can be kept alive even after the transaction commit, and be cleaned up after the whole command finishes (as determined by gp_command_id).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants