Re: 7.2 crash... - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: 7.2 crash...
Date
Msg-id 200203220504.g2M54d621486@candle.pha.pa.us
Whole thread Raw
In response to Re: 7.2 crash...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Tom Lane wrote:
> "Rod Taylor" <rbt@zort.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?

Well, this could would be in vacuum.c, right?  Seems like a nice
central location for it.  I don't see it as terribly ugly only because
the issue is that we can't run vacuum inside a memory context that can't
be free'ed by vacuum.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: 7.2 crash...
Next
From: pgsql-bugs@postgresql.org
Date:
Subject: Bug #623: Compling 7.2 on a Tru64 V5.1 UNIX