Re: plpgsql functions crash cvs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, Neil Conway <neilc(at)samurai(dot)com>
Subject: Re: plpgsql functions crash cvs
Date: 2006-03-02 01:35:34
Message-ID: 18618.1141263334@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Kris Jurka <books(at)ejurka(dot)com> writes:
> eKol in #postgresql reported a problem with a plpgsql function crashing
> the server. I tested the attached against 8.2cvs as of this morning
> and got this stacktrace:

> #0 plpgsql_xact_cb (event=XACT_EVENT_COMMIT, arg=0x0) at pl_exec.c:4521

I believe this is new as of 8.1. The problem is that we are chasing a
list threaded through plpgsql parse structures, and since Neil's cleanup
of plpgsql space management about a year ago, those structures are no
longer guaranteed to remain in existence throughout a backend's run.
In particular, modifying the definition of a function (in this example,
by doing a REVOKE on it) when it's been used earlier in the same
transaction can lead to a dangling pointer being chased at transaction
end.

On reflection I don't see any need for the explicit list. We are using
it just to help keep track of whether simple expressions have been
initialized in the current transaction. It'd be better to store the
value of GetTopTransactionId into a simple expression when we init it,
and then assume it's OK as long as this matches.

Thanks for the report!

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Josemir Castro 2006-03-02 02:16:44 Extensão de uma Base de Dados Postgresql
Previous Message Alvaro Herrera 2006-03-02 01:22:25 Re: plpgsql functions crash cvs