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 with maintaining more state (keep extra pre-computed values, even when they are never used) so I think we should avoid it.