From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Rod Taylor" <rbt(at)zort(dot)ca> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: 7.2 crash... |
Date: | 2002-03-22 04:22:58 |
Message-ID: | 28474.1016770978@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
"Rod Taylor" <rbt(at)zort(dot)ca> writes:
> 7.2 crashes with the below function:
> CREATE OR REPLACE FUNCTION runMaintenance()
> RETURNS BOOL AS '
> VACUUM;
> SELECT TRUE;
> ' LANGUAGE sql;
AFAICS there is no way that we can support VACUUM inside a function;
the forced transaction commits that VACUUM performs will recycle any
memory allocated by the function executor, leading to death and
destruction upon return from VACUUM.
Accordingly, what we really need is a way of preventing VACUUM from
executing in the above scenario. The IsTransactionBlock() test it
already has isn't sufficient.
I have thought of something that probably would be sufficient:
if (!MemoryContextContains(QueryContext, vacstmt))
elog(ERROR, "VACUUM cannot be executed from a function");
This is truly, horribly ugly ... but it'd get the job done, because only
interactive queries will generate parsetrees in QueryContext.
Can someone think of a better way?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-03-22 05:04:39 | Re: 7.2 crash... |
Previous Message | Tom Lane | 2002-03-20 05:25:09 | Re: 7.2 crash... |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2002-03-22 04:36:05 | Re: Where to get official SQL spec (was Re: Domain Support) |
Previous Message | Nicolas Bazin | 2002-03-22 04:20:51 | Re: Where to get official SQL spec (was Re: Domain Support) |