Re: Keeping state in a foreign data wrapper - Mailing list pgsql-general

From Ian Barwick
Subject Re: Keeping state in a foreign data wrapper
Date
Msg-id 074df913-4d7b-b392-6870-0bee49003f92@2ndquadrant.com
Whole thread Raw
In response to Re: Keeping state in a foreign data wrapper  (Stelios Sfakianakis <sgsfak@gmail.com>)
List pgsql-general
On 2020/08/04 19:21, Stelios Sfakianakis wrote:
 > Thank you again, I have another question in order to make sure I have a clear understanding:
 >
 >
 >> On 4 Aug 2020, at 11:24, Ian Lawrence Barwick <barwick@gmail.com> wrote:
 >>
 >> The hash table is specific to each running backend so will only be
 >> accessed by that process.
 >>
 >> Pre-loading a shared library just gives the library an opportunity to
 >> set up shared memory etc. You can always try adding one of the FDW
 >> libraries to "shared_preload_libraries" and see what happens
 >> (theoretically nothing).
 >>
 >
 > My impression was that since each client (e.g. libpq) connection results in the creation of a Postgres process in
thebackend (https://www.postgresql.org/developer/backend/) then this  (mysql) "connection pool" hash table is not
globalper se and shared among the different client / users sessions.
 

Correct, the connections are specific to each individual backend.

 > But that defeats the purpose, no?

The purpose is to cache connections within the session, to avoid the overhead
of reconnecting to the remote server each time a query for that server is issued
in that session.


Regards

Ian Barwick



-- 
Ian Barwick                   https://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services



pgsql-general by date:

Previous
From: Ian Barwick
Date:
Subject: Re: Keeping state in a foreign data wrapper
Next
From: Flaris Roland Feller
Date:
Subject: Re: ERROR: invalid memory alloc request size 18446744073709551613