On Tue, Oct 6, 2020 at 7:22 PM Masahiko Sawada <masahiko.saw...@2ndquadrant.com> wrote: > > On Fri, 2 Oct 2020 at 18:20, tsunakawa.ta...@fujitsu.com > <tsunakawa.ta...@fujitsu.com> wrote: > > > > From: Masahiko Sawada <masahiko.saw...@2ndquadrant.com> > > > You proposed the first idea > > > to avoid such a situation that FDW implementor can write the code > > > while trying to reduce the possibility of errors happening as much as > > > possible, for example by usingpalloc_extended(MCXT_ALLOC_NO_OOM) and > > > hash_search(HASH_ENTER_NULL) but I think it's not a comprehensive > > > solution. They might miss, not know it, or use other functions > > > provided by the core that could lead an error. > > > > We can give the guideline in the manual, can't we? It should not be > > especially difficult for the FDW implementor compared to other Postgres's > > extensibility features that have their own rules -- table/index AM, > > user-defined C function, trigger function in C, user-defined data types, > > hooks, etc. And, the Postgres functions that the FDW implementor would use > > to implement their commit will be very limited, won't they? Because most > > of the commit processing is performed in the resource manager's library > > (e.g. Oracle and MySQL client library.) > > Yeah, if we think FDW implementors properly implement these APIs while > following the guideline, giving the guideline is a good idea. But I’m > not sure all FDW implementors are able to do that and even if the user > uses an FDW whose transaction APIs don’t follow the guideline, the > user won’t realize it. IMO it’s better to design the feature while not > depending on external programs for reliability (correctness?) of this > feature, although I might be too worried. >
+1 for that. I don't think it's even in the hands of implementers to avoid throwing an error in all the conditions. -- Best Wishes, Ashutosh Bapat
