Hi, Albe, Thank you.
The resource is not memory, I have something like a file descriptor or network connection, which I believe is the common case for foreign table. Using RegisterXactCallback exposes an API at a much deep level to foreign table writer, and I need to find a place to anchor the context (fdw_state). I took a look at postgres_fdw and found that xact callback is exactly what is done. So I will take this approach. Again, thank you Albe, for pointing me to it. Feng On Mon, Dec 14, 2015 at 12:30 AM, Albe Laurenz <laurenz.a...@wien.gv.at> wrote: > Feng Tian wrote: > > I need some help to understand foreign table error handling. > > > > For a query on foreign table, ExecInitForeignScan is called, which in > turn calls the BeginForeignScan > > hook. Inside this hook, I allocated some resource, > > > > > > node->fdw_state = allocate_resource(...); > > > > If everything goes well, ExecEndForeignScan will call call my > EndForeignScan hook, inside the hook, I > > free the resource. > > > > free_resource(node->fdw_state); > > > > However, if during the execution an error happened, seems to me that > EndForeignScan will not be called > > (traced using gdb). So my question is, is Begin/End the right place > for allocate/free resources? > > If it is not, what is the right way to do this? > > If the resource is memory, use "palloc" to allocate it, and PostgreSQL > will take care of it automatically. > > Other than that, you could call RegisterXactCallback() and register a > callback > that will be called upon transaction end. In the callback function you can > free the resource if it was not already freed by EndForeignScan. > > Yours, > Laurenz Albe >
