On Fri, Jan 18, 2019 at 10:39:46AM -0500, Robert Haas wrote:
> Huh. Well, in that case, I'm not sure I understand we really need to
> do beyond removing the error checks for the case where all tables are
> on-commit-drop.
I have not looked at the patch in details, but we should really be
careful that if we do that the namespace does not remain behind when
performing such transactions so as it cannot be dropped. On my very
recent lookups of this class of problems you can easily finish by
blocking a backend from shutting down when dropping its temporary
schema, with the client, say psql, already able to disconnect. So as
long as the 2PC transaction is not COMMIT PREPARED the backend-side
wait will not be able to complete, blocking a backend slot in shared
memory. PREPARE TRANSACTION is very close to a simple commit in terms
of its semantics, while COMMIT PREPARED is just here to finish
releasing resources.
> It could be useful to do something about the issue with pg_temp
> creation that Tom linked to in the other thread. But even if you
> didn't do that, it'd be pretty easy to work around this in application
> code -- just issue a dummy CREATE TEMP TABLE .. ON COMMIT DROP
> statement the first time you use a connection, so that the temp schema
> definitely exists. So I'm not sure I'd view that as a blocker for
> this patch, even though it's kind of a sucky limitation.
That's not really user-friendly, still workable. Or you could just
call current_schema() ;)
--
Michael