Robert Haas <robertmh...@gmail.com> writes:
> On Sat, Feb 20, 2016 at 1:43 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 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.
Hmm, mumble. This assumes that the "FDW" is willing to keep its data
in something that looks externally just like a Postgres heap file (as
opposed to, say, keeping it somewhere else in the filesystem). That
pretty much gives up the notion that this is "foreign" data access and
instead means that you're trying to force-fit an alternate storage
manager into our FDW-shaped slot. I doubt it will fit very well.
For one thing, we have never supposed that FDWs were 100% responsible
for managing the data they access, which is why they are not hooked up
to either DROP or a boatload of other maintenance activities like VACUUM,
CLUSTER, REINDEX, etc. Not to mention that an alternate storage manager
might have its own maintenance activities that don't really fit any of
those concepts.
> If you then also had the generic XLOG patch, maybe you could make it
> WAL-logged, too, if you wanted...
While I've not paid close attention, I had the idea that the "generic
XLOG" patches that have been discussed would still be restricted to
dealing with data that fits into Postgres-style pages (because, for
example, it would have to pass bufmgr's page sanity checks). That's a
restriction that an alternate storage manager would likely not want.
My point remains that building anything actually useful in this space
is not a small task.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
