From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Richard Huxton <dev(at)archonet(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Islam Hegazy <islheg(at)hotmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: modifying the tbale function |
Date: | 2007-03-19 23:27:08 |
Message-ID: | 45FF1C4C.8030003@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2007-03-19 23:38:32 | pgsql: Changes pg_trigger and extend pg_rewrite in order to allow |
Previous Message | Florian G. Pflug | 2007-03-19 23:17:29 | Re: modifying the tbale function |