add: per request statement timeout using prefer header

[taimoorzaeem]

Adds a feature to set statement_timeout using Prefer: timeout header. This also introduces a PGRST129 error which is returned when the timeout preferred exceeds the per-role timeout, which prevents misuse of this feature.

Closes #4381.

• Implementation
• Tests
• Docs

[steve-chavez]

We should also fail in case a value exceeds the per role timeout. Otherwise it's abusable.

This failure should happen at the plan level, before hitting the db. I think it will need a new error code.

[steve-chavez]

I'm confused by all of this logic, why do we need to parse a time unit?

[taimoorzaeem]

We should also fail in case a value exceeds the per role timeout. Otherwise it's abusable

I'm confused by all of this logic, why do we need to parse a time unit?

That's because the statement_timeout value of the role could be like 1min or 100ms depending upon the role. So, we need to throw an error depending on whether the timeout exceeds role setting or not and for that, we must parse the value, I think.

[steve-chavez]

Can we do the conversion in postgres to avoid the parsing? For example with:

select extract(epoch from current_setting('statement_timeout', false)::interval)::int;

That should give you the number of seconds regardless of the input format.

[taimoorzaeem]

That's great.

However, if we do this conversion at the time of querying the role settings, that would change the original role settings, which we explicitly add to pre-query (BTW, I'm not sure why we do this, wouldn't postgres already know the settings?) here:

postgrest/src/PostgREST/Query/PreQuery.hs

Line 51 in 8f5fe3f

roleSettingsSql = setConfigWithDynamicName <$> HM.toList (fromMaybe mempty $ HM.lookup authRole configRoleSettings)

So, we would then have to keep the two sets of role settings, one with the conversion applied on and the original ones without the conversion.

[wolfgangwalther]

we explicitly add to pre-query (BTW, I'm not sure why we do this, wouldn't postgres already know the settings?)

The settings set via ALTER ROLE ... only apply when logging in with that role. PostgreSQL does not apply them when doing a SET ROLE. That means, these role-specific settings are only set when we do it manually.

[steve-chavez]

@taimoorzaeem Hm, so we can't avoid this logic with the above snippet?

[taimoorzaeem]

Yes. If we try to avoid this logic using the above snippet, we would end up with maintaining more state (keep extra pre-computed values, even when they are never used) so I think we should avoid it.

[steve-chavez]

Sorry for late reply here.

If we try to avoid this logic using the above snippet, we would end up with maintaining more state (keep extra pre-computed values, even when they are never used) so I think we should avoid it.

IMO we should cache the pg transformed value.

• Having to repeat this transformation logic for each request at the Plan level would be inefficient.
• It's not much more memory considering we only take child roles of the connection role:
  

  postgrest/src/PostgREST/Config/Database.hs

  Line 145 in ffa3938

  where member = current_user::regrole::oid

• Also later on we could avoid this caching if Prefer: timeout is not used with Config flag for enabling/disabling preferences #2987.
• There is more risk for errors with this Haskell logic.. say if pg changes format of the statement_timeout, very unlikely but overall it feels safer to have the transformation at the db level.

[taimoorzaeem]

IMO we should cache the pg transformed value

@steve-chavez How about an internal config to store the transformed values?

[steve-chavez]

Yes, this looks much better 👍