Re: observations about temporary tables and schemas

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Kris Jurka" <books(at)ejurka(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "Rod Taylor" <rbt(at)rbt(dot)ca>
Subject: Re: observations about temporary tables and schemas
Date: 2003-09-17 15:04:56
Message-ID: 303E00EBDD07B943924382E153890E5434A9D7@cuthbert.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> I think we have two choices: disallow foreign-key references from temp
> tables to permanent tables, or take out the optimization of storing
> temp table pages in private memory. (That would leave the whole
> buffer manager" module as dead code, I think.) I'm kinda leaning
> towards the first; does anyone feel that it's a valuable feature to

I would hate to lose 'memory optimized' temp tables unless the arguments
for were compelling and there was no other solution.

> That is not the same bug; the problem here is that ON COMMIT DELETE
> simply does an unconditional heap_truncate without bothering to run
> deletion triggers. We could make it apply the same checks TRUNCATE
> TABLE does, whereupon you'd get some sort of "can't truncate table"
> error when you try to set up a foreign key reference to it. That
> be extended to disallowing the FK reference in the first place,
> Or we could turn it into a "DELETE FROM temptable", which would be a
> slower but would "do the right thing". Comments?

This seems correct from one point of view, but what happens when a
delete trigger fails? Instead of 'DELETE FROM', what about

This seems be consistent with other commands. For example, when a temp
table has domain x and another backend does DROM DOMAIN...CASCADE on x,
x is dropped from the temp table, which 'feels right'. If the temp
table fails to drop for some reason, the memory could be bulldozed like
it is now. BTW, domains are another way to bypass the 'isolation
principle' for temp tables.


Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2003-09-17 15:08:00 Re: observations about temporary tables and schemas
Previous Message Tom Lane 2003-09-17 14:26:32 Re: observations about temporary tables and schemas