Re: FDW: should GetFdwRoutine be called when drop table?

On Sat, Feb 20, 2016 at 1:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2016-02-19 14:18:19 -0500, Peter Eisentraut wrote:
>>> On 2/19/16 12:21 PM, Feng Tian wrote:
>>>> I have an fdw that each foreign table will acquire some persisted resource.
>
>>> But foreign data wrappers are meant to be wrappers around data managed
>>> elsewhere, not their own storage managers (although that is clearly
>>> tempting), so there might well be other places where this breaks down.
>
>> Sounds like even a BEGIN;DROP TABLE foo;ROLLBACK; will break this
>> approach.
>
> Yes, that's exactly the problem: you'd need some sort of atomic commit
> mechanism to make this work safely.
>
> It's possible we could give FDWs a bunch of hooks that would let them
> manage post-commit cleanup the same way smgr does, but it's a far larger
> project than it might have seemed.

I've been thinking about the idea of letting foreign data wrappers
have either (a) a relfilenode that is not zero, representing local
storage; or perhaps even (b) an array of relfilenodes. The
relfilenode, or relfilenodes, would be automatically dropped. It
seems like this would be handy for things like cstore_fdw or the
problem mentioned here, where you do want to manage local storage. If
you then also had the generic XLOG patch, maybe you could make it
WAL-logged, too, if you wanted...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company