On Tue, Sep 22, 2009 at 10:13:24AM -0400, Tom Lane wrote:
>
> Another point that comes to mind is shared_preload_libraries: if plperl
> is loaded once in the postmaster, it seems entirely likely that the same
> END block would be executed in multiple backends after having been
> loaded only once.
On Tue, Sep 22, 2009 at 10:13 AM, Tom Lane wrote:
> Robert Haas writes:
>> If the changes are simple, as Tim seems to believe, exactly what do we
>> lose by doing this?
>
> It's not simple. There are any number of issues that Tim has not
> addressed. The most obvious: *his* use case might not r
Robert Haas writes:
> If the changes are simple, as Tim seems to believe, exactly what do we
> lose by doing this?
It's not simple. There are any number of issues that Tim has not
addressed. The most obvious: *his* use case might not require database
access in an END block, but that doesn't mea
On Mon, Sep 21, 2009 at 7:30 PM, Tom Lane wrote:
> David Fetter writes:
>> On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote:
With connection poolers, backends can last quite awhile. Is it OK
for the END block to run hours after the rest of the code?
>>>
>>> This is an int
On Mon, Sep 21, 2009 at 07:30:51PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote:
> >>> With connection poolers, backends can last quite awhile. Is it OK
> >>> for the END block to run hours after the rest of the code?
Yes.
> >>
David Fetter writes:
> On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote:
>>> With connection poolers, backends can last quite awhile. Is it OK
>>> for the END block to run hours after the rest of the code?
>>
>> This is an interesting point -- should END blocks be called on
>> DISC
On Mon, Sep 21, 2009 at 3:08 PM, Alvaro Herrera
wrote:
> David Fetter escribió:
>> On Mon, Sep 21, 2009 at 01:06:17PM -0400, Alvaro Herrera wrote:
>
>> > The fine manual saith
>> >
>> > You may have multiple "END" blocks within a file--they will
>> > execute in reverse order of definition;
David Fetter escribió:
> On Mon, Sep 21, 2009 at 01:06:17PM -0400, Alvaro Herrera wrote:
> > The fine manual saith
> >
> > You may have multiple "END" blocks within a file--they will
> > execute in reverse order of definition; that is: last in, first
> > out (LIFO).
> >
> > But then,
On Mon, Sep 21, 2009 at 02:28:11PM -0400, Robert Haas wrote:
> On Mon, Sep 21, 2009 at 2:17 PM, David Fetter wrote:
> > On Mon, Sep 21, 2009 at 01:06:17PM -0400, Alvaro Herrera wrote:
> >> David Fetter escribió:
> >> > On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote:
> >> > > David
On Mon, Sep 21, 2009 at 2:17 PM, David Fetter wrote:
> On Mon, Sep 21, 2009 at 01:06:17PM -0400, Alvaro Herrera wrote:
>> David Fetter escribió:
>> > On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote:
>> > > David Fetter escribió:
>> > >
>> > > > Taken literally, that would mean, "the
On Mon, Sep 21, 2009 at 01:06:17PM -0400, Alvaro Herrera wrote:
> David Fetter escribió:
> > On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote:
> > > David Fetter escribió:
> > >
> > > > Taken literally, that would mean, "the last action before the
> > > > backend exits," but at least
On Mon, Sep 21, 2009 at 12:06 PM, Alvaro Herrera
wrote:
> David Fetter escribió:
>
>> 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 a
David Fetter escribió:
> On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote:
> > David Fetter escribió:
> >
> > > 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 transa
On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote:
> David Fetter escribió:
>
> > 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
>
David Fetter escribió:
> 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?
The manual is clea
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 w
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 issue
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.
--
Alvaro H
On Sat, Sep 19, 2009 at 11:43:26PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Sep 19, 2009 at 3:53 PM, Tom Lane wrote:
> >> "Tim Bunce" writes:
> >>> The plperl implementation doesn't call perl_destruct() during server
> >>> shutdown.
> >>
> >> Who cares? �The process is going awa
Robert Haas writes:
> On Sat, Sep 19, 2009 at 3:53 PM, Tom Lane wrote:
>> "Tim Bunce" writes:
>>> The plperl implementation doesn't call perl_destruct() during server
>>> shutdown.
>>
>> Who cares? The process is going away anyway.
> END {} blocks can execute arbitrary code. Perl users will
On Sat, Sep 19, 2009 at 3:53 PM, Tom Lane wrote:
> "Tim Bunce" writes:
>> The plperl implementation doesn't call perl_destruct() during server
>> shutdown.
>
> Who cares? The process is going away anyway.
END {} blocks can execute arbitrary code. Perl users will expect them
to be executed.
..
"Tim Bunce" writes:
> The plperl implementation doesn't call perl_destruct() during server
> shutdown.
Who cares? The process is going away anyway.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
h
The following bug has been logged online:
Bug reference: 5066
Logged by: Tim Bunce
Email address: tim.bu...@pobox.com
PostgreSQL version: 8.4.1
Operating system: darwin
Description:plperl issues with perl_destruct() and END blocks
Details:
The plperl implementation
23 matches
Mail list logo
