On Mon, Jan 14, 2019 at 07:41:18PM +0100, Dimitri Fontaine wrote: > Thanks for the review here Tom, and for linking with the other > discussion (Álvaro did that too, thanks!). I've been reviewing it > too.
If you can look at the patch, reviews are welcome. There are quite a couple of patterns I spotted on the way. > I didn't think about the pg_temp_NN namespaces in my approach, and I > think it might be possible to make it work, but it's getting quite > involved now. > > One idea would be that if every temp table in the session belongs to the > transaction, and their namespace too (we could check through pg_depend > that the namespace doesn't contain anything else beside the > transaction's tables), then we could dispose of the temp schema and > on-commit-drop tables at PREPARE COMMIT time. Hm. A strong assumption that we rely on in the code is that the temporary namespace drop only happens when the session ends, so you would need to complicate the logic so as the namespace is created in a given transaction, which is something that can be done (at least that's what my patch on the other thread adds control for), and that no other objects than ON COMMIT tables are created, which is more tricky to track (still things would get weird with a LOCK on ON COMMIT DROP tables?). The root of the problem is that the objects' previous versions would still be around between the PREPARE TRANSACTION and COMMIT PREPARED, and that both queries can be perfectly run transparently across multiple sessions. Back in the time, one thing that we did in Postgres-XC was to enforce 2PC to not be used and use a direct commit instead of failing, which was utterly wrong. Postgres-XL may be reusing some of that :( > Yeah. The goal of my approach is to transparently get back temp table > support in 2PC when that makes sense, which is most use cases I've been > confronted to. We use 2PC in Citus, and it would be nice to be able to > use transaction local temp tables on worker nodes when doing data > injestion and roll-ups. You have not considered the case of inherited tables and partitioned mixing ON COMMIT actions of different types as well. For inherited tables this does not matter much I think, perhaps for partitions it does (see tests in 52ea6a8, which you would need to mix with 2PC). -- Michael
signature.asc
Description: PGP signature