Re: modifying the tbale function - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: modifying the tbale function
Date
Msg-id 45FF1C4C.8030003@phlo.org
Whole thread Raw
In response to Re: modifying the tbale function  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: modifying the tbale function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Gregory Stark wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
> 
>> Since context switching would occur only at two well-defined places
>> (Some return_next_row function that PLs call when a SFR returns a row,
>> and in the executor if no more previously returned rows from that SFR
>> are available), this wouldn't introduce the usual multithreading
>> headache...
> 
> Yes it would. Consider what happens if the PL function calls into SPI to
> execute a query....

I don't that would cause trouble. Postgres and the PL would still not run 
concurrently - in fact, from a control-flow point of view the PL would run at 
_exactly_ the same place as it is now. Precisely if someone tries to pull rows 
out of some executor node. The only difference is that now it's execution would
would be stopped and restarted multiple times by some sort of stack-switching.

There might be trouble if a second function has to be executed with the same PL
as an already running (but currently "stopped") function. This would only work
for PL that is thread-safe in some way.

greetings, Florian Pflug



pgsql-hackers by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: Re: modifying the tbale function
Next
From: Tom Lane
Date:
Subject: Re: modifying the tbale function