Обсуждение: libpq on the server
Hi, For various reasons (parallel structure with existing code, commonality of concepts, etc), we have C language functions implementedthat use libpq to make a new connection to the same Postgres server. Yes, I realize libpq is meant for clientsand SPI for backends. The question is, are there any technical problems with this? Will using libpq in the backenddo Bad Things in unexpected areas/ways? The environment ranges from: Postgres 7.4.2, 7.4.3 RedHat 7.3, 9.0 Thanks, Wayne
Wayne Fang <wayne@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
Thanks for the reply. At 12:10 PM 8/23/04, Tom Lane wrote: >Wayne Fang <wayne@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
Wayne Fang <wayne@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
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>)