From: | Doug McNaught <doug(at)wireboard(dot)com> |
---|---|
To: | Nic Ferrier <nferrier(at)tapsellferrier(dot)co(dot)uk> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: implemention of calls to stored procs. |
Date: | 2002-01-23 00:13:37 |
Message-ID: | m3r8oh6i1a.fsf@varsoon.denali.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Nic Ferrier <nferrier(at)tapsellferrier(dot)co(dot)uk> writes:
> I've been looking at the implementation of the procedural language
> support code with a view to writing a java plugin (ie: something to
> allow java classes to be used as stored procs).
Someone else has been talking about this--check the archives from the
last six months.
> >From what I udnerstand of the architecture it seems that the SPI API
> is inherently single threaded. I think this because of the way that
> the SPI stuff work, one calls SPI_connect and then you can do an
> SPI_exec to do a query, this sets a global value...
>
>
> Perhaps I've misunderstood the implementation details and there is
> some hidden black magic that means that more than one thread can be
> doing some SPI operations?
>
> If not, am I right? Can only one user supplied proc be running at once
> across the whole postgres engine?
The PG backend is not threaded. There is one Unix process per
connection. Each process can be running its own stored procedure
simultaneously, subject to the usual table/index locking constraints.
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-01-23 00:15:14 | Re: implemention of calls to stored procs. |
Previous Message | Nic Ferrier | 2002-01-23 00:11:09 | implemention of calls to stored procs. |