Curtis Faith wrote:
> The current transaction/user state seems to be stored in process
> global space. This could be changed to be a sointer to a struct
> stored in a back-end specific shared memory area which would be
> accessed by the executor process at execution start. The backend
> would destroy and recreate the shared memory and restart execution
> in the case where an executor process dies much like the postmaster
> does with backends now.
>
> To the extent the executor process might make changes to the state,
> which I'd try to avoid if possible (don't know if it is), the
> executors could obtain locks, otherwise if the executions were
> constrained to isolated elements (changes to different indexes for
> example) it seems like it would be possible using an architecture
> where you have:
Imagine there is a PL/Tcl function. On the first call in a session, the
PL/Tcl interpreter get's created (that's during execution, okay?). Now
the procedure that's called inside of that interpreter creates a
"global" variable ... a global Tcl variable inside of that interpreter,
which is totally unknown to the backend since it doesn't know what Tcl
is at all and that variable is nothing than an entry in a private hash
table inside of that interpreter. On a subsequent call to any PL/Tcl
function during that session, it might be good if that darn hashtable
entry exists.
How do you propose to let this happen?
And while at it, the Tcl procedure next calls spi_exec, causing the
PL/Tcl function handler to call SPI_exec(), so your isolated executor
all of the sudden becomes a fully operational backend, doing the
parsing, planning and optimizing, or what?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
