On Sat, Feb 20, 2016 at 1:43 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
