Transaction handling.

[schinckel]

I'd love to be able to replace my current "relay" process that listens for postgres NOTIFY statements, and forwards them to my Redis PUBSUB queues.

However, because NOTIFY statements only take effect at COMMIT time, the behaviour is slightly different than here, where the PUBLISH statement is handled by Redis immediately.

I understand that it is possible to write transaction handling capabilities into an FDW.

[l-d-x]

I'll have to investigate the code path that pgsql will allow this. Transactions to an fdw database that doesn't have that capability is hard to do because you have multiple insert/update/deletes that can happen at any point in time in a transaction that is not applied to the database until commit time. There isn't a simple way to temporarily cache this information to redis...

[schinckel]

Yeah, I've had a quick look too. I've been looking into how multicorn does it, and I don't think it's possible there: you get a single python object instance that lives for the lifetime of the FDW connection, not one per-transaction.

You might be able to key stuff off the transaction id, and then only send on a commit for this transaction.

(You could even store that in redis... ;)