Skip site navigation (1) Skip section navigation (2)

Re: 7.2 crash...

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 (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-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

In response to

Responses

pgsql-hackers by date

Next:From: Thomas LockhartDate: 2002-03-22 04:36:05
Subject: Re: Where to get official SQL spec (was Re: Domain Support)
Previous:From: Nicolas BazinDate: 2002-03-22 04:20:51
Subject: Re: Where to get official SQL spec (was Re: Domain Support)

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2002-03-22 05:04:39
Subject: Re: 7.2 crash...
Previous:From: Tom LaneDate: 2002-03-20 05:25:09
Subject: Re: 7.2 crash...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group