Re: Add on_perl_init and proper destruction to plperl [PATCH] - Mailing list pgsql-hackers

From Tim Bunce
Subject Re: Add on_perl_init and proper destruction to plperl [PATCH]
Date
Msg-id 20100128092551.GA38673@timac.local
Whole thread Raw
In response to Re: Add on_perl_init and proper destruction to plperl [PATCH]  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add on_perl_init and proper destruction to plperl [PATCH]  (Andrew Dunstan <andrew@dunslane.net>)
Re: Add on_perl_init and proper destruction to plperl [PATCH]  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
> Tim Bunce <Tim.Bunce@pobox.com> writes:
> > Okay. I could change the callback code to ignore calls if
> > proc_exit_inprogress is false. So an abnormal shutdown via exit()
> > wouldn't involve plperl at all. (Alternatively I could use use
> > on_proc_exit() instead of atexit() to register the callback.)
> 
> Use on_proc_exit please.  I will continue to object to any attempt
> to hang arbitrary processing on atexit().

Ok.

> An advantage of on_proc_exit from your end is that it should allow
> you to not have to try to prevent the END blocks from using SPI,
> as that would still be perfectly functional when your callback
> gets called.  (Starting a new transaction would be a good idea
> though, cf Async_UnlistenOnExit.)

I'm surprised that you're suggesting that END block should be allowed to
interact with the backend via SPI.  It seems to go against what you've
said previously about code running at shutdown.

I've no use-case for that so I'm happy to leave it disabled.  If someone
does have a sane use-case, please let me know. It can always be enabled later.

Tim.


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Review: Typed Table
Next
From: Pavel Stehule
Date:
Subject: Re: quoting psql varible as identifier