Bug in asynchronous Append - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Bug in asynchronous Append
Date
Msg-id CAPpHfduMOTnV5Zj2KGJ7zanL_10QvccZHtPUaDfJvBhsh9axnQ@mail.gmail.com
Whole thread
Responses Re: Bug in asynchronous Append
Re: Bug in asynchronous Append
List pgsql-hackers
Hi!

ExecReScanAppend() unconditionally resets callback_pending for all AsyncRequests.  The problem is that postgres_fdw keeps its own knowledge for the same fact: PgFdwConnState.pendingAreq – a pointer to "pending async request" for a given connection.  That connection can be shared by several partitions/foreign tables (postgres_fdw caches one connection per server+usermapping pair). The blind reset in nodeAppend.c only touches the local AsyncRequest.callback_pending; it never touches PgFdwConnState.pendingAreq, which correctly points to the still-dangling request.

Later, when another partition sharing that same connection gets its own ReScan (for instance, its chgParam changed because of the LATERAL parameter, and it already has a cursor open), it sends "CLOSE cursor" via pgfdw_exec_query().  Before sending any new command on the connection, that function first drains whatever request is still outstanding on it:

if (state && state->pendingAreq)
    process_pending_request(state->pendingAreq);

And process_pending_request() starts with:

Assert(areq->callback_pending);

– which fails, because the flag was corrupted some rounds earlier.

The attached patch contains both the reproduction case and the fix.  The fix postpones the reset of the callback_pending flag to ExecAppendAsyncBegin().  ExecAppendAsyncBegin() performs this cleanup along with ExecReScan(), which completes the async fetch.

------
Regards,
Alexander Korotkov
Supabase
Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: A few message wording/formatting cleanup patches
Next
From: Henson Choi
Date:
Subject: Re: Row pattern recognition