On Thu, Feb 18, 2021 at 8:38 AM Tomas Vondra <tomas.von...@enterprisedb.com> wrote: > On 2/17/21 8:36 PM, Tomas Vondra wrote: > > Thanks. The patch seems reasonable, but it's a bit too large for a fix, > > so I'll go ahead and push one of the previous fixes restricting batching > > to plain INSERT commands. But this seems useful, so I suggest adding it > > to the next commitfest. > > I've pushed the v4 fix, adding the CMD_INSERT to execPartition. > > I think we may need to revise the relationship between FDW and places > that (may) call GetForeignModifyBatchSize. Currently, these places need > to be quite well synchronized - in a way, the issue was (partially) due > to postgres_fdw and core not agreeing on the details.
Agreed. > In particular, create_foreign_modify sets batch_size for CMD_INSERT and > leaves it 0 otherwise. So GetForeignModifyBatchSize() returned 0 later, > triggering an assert. > > It's probably better to require GetForeignModifyBatchSize() to always > return a valid batch size (>= 1). If batching is not supported, just > return 1. That makes sense. How about the attached? -- Amit Langote EDB: http://www.enterprisedb.com
ForeignModifyBatchSize-sanity.patch
Description: Binary data
