Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rx0R4-005oZI-9u for pgsql-general@arkaria.postgresql.org; Wed, 17 Apr 2024 08:14:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rx0R2-009kI6-TR for pgsql-general@arkaria.postgresql.org; Wed, 17 Apr 2024 08:14:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rx0R2-009kHy-Hw for pgsql-general@lists.postgresql.org; Wed, 17 Apr 2024 08:14:28 +0000 Received: from smtp1-g21.free.fr ([212.27.42.1]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rx0Qz-001QCI-L1 for pgsql-general@lists.postgresql.org; Wed, 17 Apr 2024 08:14:27 +0000 Received: from zimbra-e1-02.priv.proxad.net (unknown [172.20.243.240]) by smtp1-g21.free.fr (Postfix) with ESMTP id 9EE31B0037C; Wed, 17 Apr 2024 10:14:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1713341664; bh=fHoWh9gMJZmfHeyDtqcBHo1ptptGQPBIKjVaJIgn9vQ=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=PJj6uVgUlIzvw5KVrR587A7/RLKktWkN9Z5KHEcn+AS08Jql1OQDBq6mqjit2deVP OSSalUEPiApMKOuKJVitN6PY+FZAVcZoBdhYxpl3E2TrsxVn3yi4uEMXGvoEQwvNSj A/jruMEKT301X9Pp70mL+UUJjm3ViE4dqmdDdLUj/NWHxGTM345D5hkmrf6TvpqbOt +CDBwnQ6SEVQqrxAKSvv/rCpYTip3TgNw01W/sZAJZv3onCpHkOGCJSJ7o+zhrpQU3 eK1EC8MzVx8TiF5QbaiK9ye1XwHqu5W408ctjF84RRzvLZkySmQGr9hlUYpwa7Ioyw TIWqLPWIqflCw== Date: Wed, 17 Apr 2024 10:14:23 +0200 (CEST) From: gparc@free.fr To: yudhi Cc: Juan Rodrigo Alejandro Burgos Mella , pgsql-general Message-ID: <1209304795.181772545.1713341663603.JavaMail.zimbra@free.fr> In-Reply-To: References: <1024954288.180821153.1713337816069.JavaMail.zimbra@free.fr> Subject: Re: Controlling resource utilization MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_d4652595-9b61-4168-ba3c-95ed8d2efe4b" X-Originating-IP: [145.242.20.127] X-Mailer: Zimbra 9.0.0_GA_1337 (ZimbraWebClient - FF115 (Linux)/9.0.0_GA_1337) Thread-Topic: Controlling resource utilization Thread-Index: Y9u+pZ3/YyjNsqwpAK9wFu8lF0PLwQ== List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --=_d4652595-9b61-4168-ba3c-95ed8d2efe4b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > De: "yudhi" > =C3=80: "gparc" > Cc: "Juan Rodrigo Alejandro Burgos Mella" , > "pgsql-general" > Envoy=C3=A9: Mercredi 17 Avril 2024 09:42:49 > Objet: Re: Controlling resource utilization > On Wed, 17 Apr, 2024, 12:40 pm , < [ mailto:gparc@free.fr | gparc@free.fr= ] > > wrote: >>> De: "Juan Rodrigo Alejandro Burgos Mella" < [ >>> mailto:rodrigoburgosmella@gmail.com | rodrigoburgosmella@gmail.com ] > >>> =C3=80: "yudhi s" < [ mailto:learnerdatabase99@gmail.com | >>> learnerdatabase99@gmail.com ] > >>> Cc: "pgsql-general" < [ mailto:pgsql-general@lists.postgresql.org | >>> pgsql-general@lists.postgresql.org ] > >>> Envoy=C3=A9: Mardi 16 Avril 2024 22:29:35 >>> Objet: Re: Controlling resource utilization >> ALTER ROLE SET statement_timeout =3D ''; >> Regards >> Gilles > Thank you so much. That helps. > This statement is succeeding for user as I executed. So it's working I be= lieve. > But to immediately verify without manually running queries and waiting fo= r it to > be auto killed to confirm, Is there any system table which we can verify = to see > if this setting is effective, as because I don't see any such columns in > pg_user or pg_role which shows the statement_timeout. > And is there a way to put similar cap/restrictions on other db resources = like > cpu, memory, I/O at specific user/role level? To verify the setting, you can use this command in psql : \drds =20 Concerning system resources like CPUs it's not possible.=20 You can use pg_settings view to see which setting you can change and in whi= ch context : [ https://www.postgresql.org/docs/current/view-pg-settings.htm= l | https://www.postgresql.org/docs/current/view-pg-settings.html ]=20 Regards=20 Gilles=20 --=_d4652595-9b61-4168-ba3c-95ed8d2efe4b Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
De: "yudhi" <learnerdatabase99@gmail.com>
= =C3=80: "gparc" <gparc@free.fr>
Cc: "Juan Rodrigo Aleja= ndro Burgos Mella" <rodrigoburgosmella@gmail.com>, "pgsql-general" &l= t;pgsql-general@lists.postgresql.org>
Envoy=C3=A9: Mercredi 17= Avril 2024 09:42:49
Objet: Re: Controlling resource utilization<= br>

On Wed, 17 Apr,= 2024, 12:40 pm , <gparc@free.fr> wrote:


De: "Juan Rodrigo Alejandro Burgos Mell= a" <rodrigoburgosmella@gmail.com<= /a>>
=C3=80: "yudhi s" <learnerdatabase99@gmail.com>
Cc: "pgsql-general" <pgsql-general@lists.postgresql.o= rg>
Envoy=C3=A9: Mardi 16 Avril 2024 22:29:35
Objet:= Re: Controlling resource utilization
ALTER ROLE <your-username> SET statement_timeout =3D '<time_unit&=
gt;';
Regards
Gilles

=


Thank you so much. That helps. 

=
This statement is succeeding for user as I executed. So i= t's working I believe. 

But to immediately verify without manually running queries and waiting= for it to be auto killed to confirm, Is there any system table which we ca= n verify to see if this setting is effective, as because I don't see any su= ch columns in pg_user or pg_role which shows the statement_timeout.

 And is there a way to put= similar cap/restrictions on other db resources like cpu, memory, I/O at sp= ecific user/role level? 
To verify the s= etting, you can use this command in psql :  \drds <your-username>= ;

Concerning system resources like CPUs it's not pos= sible.
You can use pg_settings view to s= ee which setting you can change and in which context :  https://www.pos= tgresql.org/docs/current/view-pg-settings.html
=

Regards
Gilles

--=_d4652595-9b61-4168-ba3c-95ed8d2efe4b--