467,077 Members | 949 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,077 developers. It's quick & easy.

libpq on the server

Hi,

For various reasons (parallel structure with existing code, commonality of concepts, etc), we have C language functions implemented that use libpq to make a new connection to the same Postgres server. Yes, I realize libpq is meant for clients and SPI for backends. The question is, are there any technical problems with this? Will using libpq in the backend do Bad Things in unexpected areas/ways?

The environment ranges from:
Postgres 7.4.2, 7.4.3
RedHat 7.3, 9.0

Thanks,
Wayne
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 23 '05 #1
  • viewed: 1370
Share:
4 Replies
Wayne Fang <wa***@barrodale.com> writes:
For various reasons (parallel structure with existing code,
commonality of concepts, etc), we have C language functions
implemented that use libpq to make a new connection to the same
Postgres server. Yes, I realize libpq is meant for clients and SPI
for backends. The question is, are there any technical problems with
this? Will using libpq in the backend do Bad Things in unexpected
areas/ways?


dblink does that, and I've not heard of problems, though there are
certain specific areas where you'd need to be careful due to overlap of
symbols between libpq and backend (the DLxxx functions used for
listen/notify are one such place, and there are conflicts in the
pg_wchar stuff as well). It'd be a good idea to make sure that your
custom functions will bind first to libpq and only second to the main
backend's symbols.

By the same token, don't try to link libpq statically into the backend.
But it should be possible to make it work as a dynamic link.

Realize also that this is *fundamentally* different from SPI, in that
you are controlling a separate session rather than issuing commands in
your own session. This has implications for data visibility, error
recovery, and so on. But you probably knew that already.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 23 '05 #2
Thanks for the reply.

At 12:10 PM 8/23/04, Tom Lane wrote:
Wayne Fang <wa***@barrodale.com> writes:
For various reasons (parallel structure with existing code,
commonality of concepts, etc), we have C language functions
implemented that use libpq to make a new connection to the same
Postgres server. Yes, I realize libpq is meant for clients and SPI
for backends. The question is, are there any technical problems with
this? Will using libpq in the backend do Bad Things in unexpected
areas/ways?
dblink does that, and I've not heard of problems, though there are
certain specific areas where you'd need to be careful due to overlap of
symbols between libpq and backend (the DLxxx functions used for
listen/notify are one such place, and there are conflicts in the
pg_wchar stuff as well). It'd be a good idea to make sure that your
custom functions will bind first to libpq and only second to the main
backend's symbols.


I haven't run into any symbol conflicts, so this shouldn't be a problem,
but I'll keep this around if it does come up.

By the same token, don't try to link libpq statically into the backend.
But it should be possible to make it work as a dynamic link.

Realize also that this is *fundamentally* different from SPI, in that
you are controlling a separate session rather than issuing commands in
your own session. This has implications for data visibility, error
recovery, and so on. But you probably knew that already.


Yes I did, but confirmation is always good.
There is a possible issue of libpq requiring a new backend process,
but the overall performance impact needs more thorough testing.
In theory, the size of information and amount of processing we deal
with will help hide the overhead involved.
As another consideration, SPI doesn't yet support transactions. Any idea
when this support might come about?

Thanks,
Wayne
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 23 '05 #3
Wayne Fang <wa***@barrodale.com> writes:
As another consideration, SPI doesn't yet support transactions. Any idea
when this support might come about?


You can run subtransactions (savepoints) through SPI in 8.0. The API
for this could be a bit cleaner perhaps :-( but it's doable --- plpgsql
does it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 23 '05 #4
On Mon, Aug 23, 2004 at 12:28:26PM -0700, Wayne Fang wrote:
As another consideration, SPI doesn't yet support transactions. Any idea
when this support might come about?


Not soon. Any action that goes through SPI is using the same
transaction that it was initiated in. There's no way to meaningfully
close said transaction and keep the SPI function running.

In 8.0 you are able to use the savepoint feature through SPI, so you can
partially rollback if there is an error, take appropiate action and keep
going without having to start everything again. But it will be within
one transaction.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Marco Vezzoli | last post: by
1 post views Thread by Phil Campaigne | last post: by
175 posts views Thread by Sai Hertz And Control Systems | last post: by
1 post views Thread by jbi130@yahoo.com | last post: by
2 posts views Thread by alltest1 | last post: by
15 posts views Thread by Dino Vliet | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.