Read-only access to temp tables for 2PC transactions

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