On Mon, Sep 21, 2009 at 11:05:43AM +0100, Tim Bunce wrote:
> On Sun, Sep 20, 2009 at 10:00:01PM -0400, Alvaro Herrera wrote:
> > There's a definitional problem here however. When should we call the
> > destructor? My impression is that it should happen when the calling
> > query terminates, not when the backend shuts down. I'm sure this will
> > cause other issues -- for example %_SHARED will be destroyed way too
> > early.
>
> The perlmod man page says:
>
> An "END" code block is executed as late as possible, that is, after
> perl has finished running the program and just before the interpreter
> is being exited, even if it is exiting as a result of a die() function.
> [...]
> Note that "END" code blocks are not executed at the end of a string
> "eval()": if any "END" code blocks are created in a string "eval()",
> they will be executed just as any other "END" code block of that packâ
> age in LIFO order just before the interpreter is being exited.
>
> so executing at the end of query, a transaction, or a session would be
> wrong. They should execute "as late as possible", "just before the
> interpreter being exited".
Taken literally, that would mean, "the last action before the backend
exits," but at least to me, that sounds troubling for the same reasons
that "end of transaction" triggers do. What happens when there are
two different END blocks in a session? With connection poolers,
backends can last quite awhile. Is it OK for the END block to run
hours after the rest of the code?
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
