On Tue, Oct 6, 2020 at 7:22 PM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
>
> On Fri, 2 Oct 2020 at 18:20, tsunakawa.takay@fujitsu.com
> <tsunakawa.takay@fujitsu.com> wrote:
> >
> > From: Masahiko Sawada <masahiko.sawada@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
comparedto 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
implementorwould use to implement their commit will be very limited, won't they? Because most of the commit processing
isperformed 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