Re: Keeping state in a foreign data wrapper

From: Ian Lawrence Barwick <barwick(at)gmail(dot)com>
To: Stelios Sfakianakis <sgsfak(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Keeping state in a foreign data wrapper
Date: 2020-08-04 03:25:51
Message-ID: CAB8KJ=gisTj=QKMJHWZrBjpxaDmt_sjv4F0efw6NiiP_MMqM6A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2020年8月4日(火) 1:24 Stelios Sfakianakis <sgsfak(at)gmail(dot)com>:
>
> Hi,
>
> I am trying to implement a FDW in Postgres for accessing a web api and I would like to keep information like for example the total number of requests submiited. Ideally these data should be kept “per-user” and of course with the proper locking to eliminate race conditions. So the question I have is how to design such a global (but per user and database) state, using the C FDW API of Postgres. I have gone through the API and for example I see various fdw_private fields in the query planning structures and callbacks but these do not seem to be relevant to my requirements. Another possiblity seems to be to use shared memory (https://www.postgresql.org/docs/12/xfunc-c.html#id-1.8.3.13.14) but it is even less clear how to do it.

Shared memory would probably work; you'd need to load the FDW via
"shared_preload_libraries" and have the FDW handler function(s) update
shared memory with whatever statistics you want to track. You could
then define SQL functions to retrieve the stored values, and possibly
persist them over server restarts by storing/retrieving them from a
file.

Look at "pg_stat_statements" for a good example of how to do that kind of thing.

Regards

Ian Barwick

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Paul Förster 2020-08-04 05:32:40 Re: Configuring only SSL in postgres docker image
Previous Message David Rowley 2020-08-04 01:33:48 Re: bad JIT decision