may be postgres can use same way like triggers working, and when relation is droping ( what is equal to delete from pg_class) there could be something like trigger after .. which can waiting for CREATE or DROP command, and then clean-up cache, (for each backend). This could be for example same message, not just trigger (i said trigger only to show scheme of acction)
ehheh this idea is also wrong ?
Ivan,
I really appreciate that you are thinking about this problem. But you keep talking about it as if this would be some sort of shared buffer cache. Do you know what a saved SPI execution plan is?
Your idea is neither bad nor new, there actually is a so called system cache invalidation event propagated to every backend in the case of catalog changes, so that it can purge it's syscache. But can you tell me how to actually check if a saved SPI plan references that particular catalog object or not?
Jan
On Wed, 31 Dec 2003, Jan Wieck wrote:
ivan wrote:
why all backend can not using one cache, which would be alwaysVariable sized shared memory with garbage collection for SPI plans?
in real state ... or i can just clear only my cache, at first
(if i know that this relation could has another oid)
and then normal using relations ?
As said, that is not sufficient. The user who does the DDL statement can as well reconnect to the database to recompile all saved plans. It is the 200 persistent PHP DB connections that suffer from not finding the index any more.
or ... just turn off cache, because its strange to has possibleDo you have any numbers about how that would affect performance?
using drop, create etc in function, but using only EXECUTE ..
Jan
there must be same solution .. no ?
On Wed, 31 Dec 2003, Jan Wieck wrote:
ivan wrote:
You obviously did not bother to search the archives on this.as new know plpgsql has special cache which remember too long (event non-existing tables (i mean old oid)) so i suggest to create same function only in plpgsql which would clear this cache, or sth like this ?
for ie, where i drop table i would do plpgsql_clear_cache (); and when i will create one more time table with this same name plpgsql will not remeber wrong oid
possible ?
This will not solve the problem since the "cache" you're talking about is per backend local memory. So if one backend modifies the schema, how does it cause all other to forgt? Since the same problem exists in general for everything that uses SPI, the solution lies in there.
Jan
--
#======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
--
#======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
