Expose Rust internal data as Postgres table?

1

  1. I am aware of GitHub - gluesql/gluesql: GlueSQL is quite sticky. It attaches to anywhere. but it's not what I'm looking for.

  2. I would like a way to query the stats of a RUNNING/LIVE Rust server via Postgres; and possibly even modify some configs dynamically.

  3. is there a way to have a Rust server implement some trait and then gain the ability for it to be viewed as readonly/writeable table in Postgres ?

2

bump

3

I suspect the answer to 2 and 3 are no. You'd likely have to have your app periodically query postgresql for changes to a config table and periodically update postgresql tables for the other direction.

4

Hmm, maybe I phrased my question poorly. Let's restart.

  1. Postgres allows custom backends for storages / tables right ?

  2. We can write these custom backends in Rust ?

  3. Is there a Rust crate that makes it easy to write such backends in Rust ?

If the answer to #3 is yes, I'm going to have my Rust server impl these traits, so postgres can query it; and when postgres does a write, it triggers a write function in my Rust server, which then causes the config to update the runtime.

5

This looks promising: GitHub - pgcentralfoundation/pgrx: Build Postgres Extensions with Rust!

1 Like
6

Quoting section caveats:

Caveats & Known Issues
There's probably more than are listed here, but a primary things of note are:

Threading is not really supported. Postgres is strictly single-threaded. As such, if you do venture into using threads, those threads MUST NOT call any internal Postgres function, or otherwise use any Postgres-provided pointer. There's also a potential problem with Postgres' use of sigprocmask. This was being discussed on the -hackers list, even with a patch provided, but the conversation seems to have stalled (PostgreSQL: Re: Threading in BGWorkers (!)).

How to correctly interact with Postgres in an async context remains unexplored.

pgrx wraps a lot of unsafe code, some of which has poorly-defined safety conditions. It may be easy to induce illogical and undesirable behaviors even from safe code with pgrx, and some of these wrappers may be fundamentally unsound. Please report any issues that may arise.`

Is there a 'safer' alternative, or is this just the way it is (due to Postgres arch decisions) for Postgres / Rust extensions ?

7

Welcome to the world of code which predates C-11 and C++-11. It was the wild west of thread safety. No memory model had become dominate yet so everyone did as they pleased and prayed that GCC's optimizer wouldn't trash their code with invented writes or unwanted load/store reordering in spite of volatile abuse.

1 Like
8

Assuming you have some application server, there's no reason you can't write the Rust code to do these things. This is a state syncing problem between your application and Postgres itself -- I don't think something like this exists already but you could certainly write it.

For #2 you can imagine writing the code to define the state, maintain it on the rust side, sync it with postgres periodically and allow for modification on the Rust/PG side.

For #3 of course you can create a proc macro that does all this for you -- but it's probably a better idea to make some sort of DbSyncedStatus<T> struct people can use.

You're probably going to need to make heavy use of async/await and related tokio/other async runtime tooling to make what you want happen reasonably (ex. tokio's watch)

Is there anything that makes you think you couldn't write it? Or were you just hoping something existed already that people could point you to?

9

I think this is the point of crates.io -- to use code other people have written. :slight_smile:

10

It's doable, though I doubt you will find example in Rust.

1 Like
11

  1. This looks really interesting.

Is GitHub - supabase/wrappers: Postgres Foreign Data Wrapper development framework in Rust. a counter example, or does it do something else ?

12

I didn't know that one, so that should make whole thing easier.

1 Like