SUGGESTION - api "signal handler" to reset cache - SIGUSR1

[mpasquini]

It is possible to have an api call to the signal handler ?

Before reporting a bug:
If your database schema has changed while the PostgREST server is running,
send the server a SIGUSR1 signal or restart it(http://postgrest.org/en/stable/admin.html#schema-reloading)
to ensure the schema cache is not stale. This sometimes fixes apparent bugs.

From GNU:

These signals are used for various other purposes. In general, they will not affect your program unless it explicitly uses them for something.

Macro: int SIGUSR1
Macro: int SIGUSR2

The SIGUSR1 and SIGUSR2 signals are set aside for you to use any way you want. They’re useful for simple interprocess communication, if you write a signal handler for them in the program that receives the signal.

[wolfgangwalther]

It is possible to have an api call to the signal handler ?

I'm not sure I undestand what you mean - but are you maybe looking for #1542 ? (not released yet)

[steve-chavez]

I think @mpasquini might be referring to calling SIGUSR1 through an endpoint, like /internal/sigusr1.

It kind of reminds to #1526 in this regard.

[wolfgangwalther]

Ah, ok. That could be done with something like the following already?

CREATE FUNCTION sigusr1() RETURNS void
LANGUAGE plpgsql AS $$
BEGIN
  NOTIFY pgrst;
END
$$;

And then call it via POST /rpc/sigusr1.

Of course db-channel-enabled=true needs to be set.

[wolfgangwalther]

Can this be closed?

[steve-chavez]

Of course db-channel-enabled=true needs to be set.

Maybe we should default db-channel-enabled to true. We disabled it because of connection poolers #1542 (comment). However dwagin told us(#1633 (comment)) that hasql-transaction still needs to be patched for poolers to work. We can put a warning about disabling db-prepared-statements and db-channel-enabled for poolers to work later on, when we're sure we work with them.

[wolfgangwalther]

Yes, I agree. In general, we should have a default config that works well for "basic" cases and does not need beginners to set up that much. I'd rather have to tell advanced users that they need to adjust their settings to support connection poolers, than beginners missing out on things like prepared statements for good performance. The same goes for db-channel-enabled - it does no harm in a regular setup.