Tom Lane <tgl@sss.pgh.pa.us> writes:
> 1. If you forget to drop the temp table before ending the script,
> then when the session ends and the temp table is forcibly dropped,
> the whole extension goes away (following the rule that a forced drop
> of an extension member makes the whole extension go away). This is
> mildly annoying, but since not dropping the temp table is a clear bug
> in an extension script, I think we can live with it.
Could we force temp tables created in an extension script to be ON
COMMIT DROP so that CurrentExtensionObject is still set and your patch
kicks in, preventing the DROP cascading?
> 2. #1 applies only in the typical case where the backend's temp table
> schema already exists. Otherwise, when we create the pg_temp_N schema
> it gets listed as one of the extension's objects. Then, when you exit
> the session, this happens (behind the scenes; it's logged in the
> postmaster log but not shown to the client):
>
> FATAL: cannot drop schema pg_temp_2 because extension myext requires it
> HINT: You can drop extension myext instead.
Interesting.
> This is really bad: any temp tables created in this session won't be
> cleaned out. And the same for any temp tables created in future
> sessions using the same backend ID slot, since they'll get the identical
> error on exit. Even worse, if you decide to drop the extension, you
> might be taking out temp tables that belong to some active session other
> than your own. Given those hazards and the fact that there's no
> reasonable way for an extension script to avoid the risk, I think this
> one is a must-fix.
>
> I don't see any easy way around this one other than kluging temp-schema
> creation to not link the temp schema to the active extension. Which is
> exactly what I'd not wanted to do in ATRewriteTable. The one bright spot
> about it is that temp-table schemas are inherently a special case
> because of their weird creation process, so we could have some comfort
> that there are probably not other similar bugs lurking.
Yeah protecting against the temp schema special case (can't be
registered as a dependency against an extension object) seems good to
me, and I'm not able to think about a better answer here.
We might want to protect in the same way against temp schema explicitly
created by the extension script too (IIRC you can actually do that): it
could be just about documentation, but if that's not too much contorting
the code it would be better to just ERROR out, I think.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
