Hi, That is an attempt number N+1 to relax checks for a temporary table access in a transaction that is going to be prepared.
One of the problems regarding the use of temporary tables in prepared transactions is that such transaction will hold locks for a temporary table after being prepared. That locks will prevent the backend from exiting since it will fail to acquire lock needed to delete temp table during exit. Also, re-acquiring such lock after server restart seems like an ill-defined operation. I tried to allow prepared transactions that opened a temporary relation only in AccessShare mode and then neither transfer this lock to a dummy PGPROC nor include it in a 'prepare' record. Such prepared transaction will not prevent the backend from exiting and can be committed from other backend or after a restart. However, that modification allows new DDL-related serialization anomaly: it will be possible to prepare transaction which read table A; then drop A; then commit the transaction. I not sure whether that is worse than not being able to access temp relations or not. On the other hand, it is possible to drop AccessShare locks only for temporary relation and don't change behavior for an ordinary table (in the attached patch this is done for all tables). Also, I slightly modified ON COMMIT DELETE code path. Right now all ON COMMIT DELETE temp tables are linked in a static list and if transaction accessed any temp table in any mode then during commit all tables from that list will be truncated. For a given patch that means that even if a transaction only did read from a temp table it anyway can access other temp tables with high lock mode during commit. I've added hashtable that tracks higher-than-AccessShare action with a temp table during current transaction, so during commit, only tables from that hash will be truncated. That way ON COMMIT DELETE tables in the backend will not prevent read-only access to some other table in a given backend. Any thoughts? -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
2PC-ro-temprels.patch
Description: Binary data
