idle_in_transaction_session_timeout, statement_timeout behandeln

aktuell wird im kea-code statement_timeout auf 30s gesetzt. das duerfte wirkungslos sein, solange in den api-procedures jeweils 2s eingestellt sind. beide einstellungen sollten wir moeglichst niedrig halten, um eine ueberlastung des masterservers zu vermeiden. zu tun:

• vereinheitlichen der einstellungen f. idle_in_transaction_session_timeout, statement_timeout: also entweder komplett kea-seitig definieren oder komplett im pl/pgsql-api-code.
• die jeweilige timeout-exception kann nur (und muss daher) im kea-code abgefangen und behandelt werden. behandlung: z.b. nach einer zufalls-wartezeit (zw. 5s und 10s?) den aufruf wiederholen. das ganze nach einer maximalzahl von wiederholungen (5?) endgueltig mit einer fehlerlogmeldung abbrechen.

assigned to @rainer.steinmueller and @janis.streib

closed with commit 2e8fe21c

reopened

marked the checklist item vereinheitlichen der einstellungen f. idle_in_transaction_session_timeout, statement_timeout: also entweder komplett kea-seitig definieren oder komplett im pl/pgsql-api-code. as completed

Zu ersterm: Ist aus dem kea-code entfernt.

wir koennen ueberlegen, ob es besser ist, alle diese timeout-params geschlossen im kea-code zu halten, oder im pgsql-code. also jeweils alternativ.

nach tests hat sich gezeigt, dass es besser ist, alle client-parameter client-seitig zu setzen, dh. im kea-code. alternativ: die parameter in postgresql.conf setzen (ansible: roles/netdb_common/templates/postgresql_conf.d/dhcpd/client_conn_dflts.conf)

m.e. hat postgres da ein etwas komisches verhalten bei der transaktionsbehandlung in den prozeduren. insbesondere gibt es kein explizites TA-start-kommando, sondern die TA beginnt immer implizit mit dem ersten sql-statement in der prozedur. dadurch werden die client-params, wenn sie in der prozedur-internen TA gesetzt werden, nicht wirksam.

demnach also kea-seitig oder postgresql.conf-seitig oder in separater prozedur (die dann je session vor jedem api-call aufgerufen werden muss) setzen:

• default_transaction_isolation = 'serializable'
• statement_timeout = '1s'
• idle_in_transaction_session_timeout = '2s'

der exception handler innerhalb der api-prozeduren wuerde dann z.b. fuer statement_timeout funktionieren, so dass man dort die shard-state-tabelle modifizieren koennte.

wie besprochen: wir nehmen die variante 'separate prozedur'. aufruf als parameterlose prozedur:

call dhcpd.api_set_clnt_sess_params()

bei jeder neuen session. ich bereite dann den code mit shard-state-logik etc. vor.

ist jetzt aktiviert. mal sehen, wie weit es gutgeht.

Deployed.

sehe wieder zuviele serialization errors. da ist noch was falsch bzw. ich hab sogar einen neuen fehler reingebaut. muss weitersuchen.

jetzt sieht es wieder gut aus. (nach update)

mentioned in commit 0908e093