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 1tBBjq-002Mag-No for pgsql-general@arkaria.postgresql.org; Wed, 13 Nov 2024 11:40:46 +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 1tBBjo-00Dg1i-33 for pgsql-general@arkaria.postgresql.org; Wed, 13 Nov 2024 11:40:44 +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 1tBBjn-00Dg1Z-OR for pgsql-general@lists.postgresql.org; Wed, 13 Nov 2024 11:40:44 +0000 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tBBjg-001iDJ-E5 for pgsql-general@lists.postgresql.org; Wed, 13 Nov 2024 11:40:43 +0000 Received: by mail-ed1-x542.google.com with SMTP id 4fb4d7f45d1cf-5cb615671acso4997737a12.1 for ; Wed, 13 Nov 2024 03:40:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731498037; x=1732102837; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j0EFegHEzr14ZaQGrCN4OR/4U2MC9UqvdX9e/LUdGwg=; b=BIeTPwt7eV/ONYZx373NfrD1rXjwTeYuL8R/WXe+drMfsuNtAfEA+GB2c1mXMC5re0 tDFwGzu8Rkn836X7RDjtR7oHD7kWDowixehbLXhRIKuU8I/V29cnrvrQiQpDrFmx6MTU CKbcU+wHPW0VZfEnxYEqTtfnMFtruEeRQmefxlGdShSm4yJFuuO6RSNNG+SwihmyDIlC 39kEJ5A4he6Uxzdmsy0tJgMD8EfK1iBdWTRYPjFbGjLQ3yx7JXe6Pxr4El9cYkJcvq8N XWN9rV2PRKrp15aeZ9OPVZ9tdjj13piMg3D1XIMf+X1OwItwD71UFtpOY2/7l1l8G6KJ bnDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731498037; x=1732102837; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j0EFegHEzr14ZaQGrCN4OR/4U2MC9UqvdX9e/LUdGwg=; b=sbH4jZUo97TPC0oCF/IDK0Dq0jaSXAX2P5FicEJECdyFwfEK/xn5sQn2Jjhin/sl6r s9gbmy26djnDdFVckb/yuVRZn1xmlG+L9GkBMS9svgB9l6ikRt8himrkmv1HIWJfhtQy iEPTJSMDD+26EkD2p6GbPtagbxpnMHBIvGz0vytX1Z6E+rIgaL/yRcM7fxCGUr2pUX2T L386FTKonB3Upx07E8RIwe5OHCLMcBithTgR9/Ji3hXRNDyXHhEuJmljIRbp32UREbl4 0IGyYdVaf/wd3ZdmHMUlJ2YVkpszcrKhhMrCnsWJOvEYal4b8cvQBHKd3+Gu/Jk/q0pF AFfA== X-Gm-Message-State: AOJu0YyH5Rn/hngbAnGfZGLW5TafWjpe7GxUT+GLoT0A9n4Wtfl2H1L0 0iOkW3H0JWZiQzCbiYRSWYgQwAIHofRqEGDogyCgsZXWgwZ8ZdfzNah1DlbL2SO19XHyrVpGy2y RGJgM0IpFAefh2EEz6hCcF9syGw/jC8HB X-Google-Smtp-Source: AGHT+IFsCo4dQVQuAlOYYamgWQUxiD/f1GCC6bOWxD2ycai1BpftisorFAUVL/XVCeWqFkc8o43LBVvf4+YgDZpvN4I= X-Received: by 2002:a05:6402:4405:b0:5ce:d435:c26d with SMTP id 4fb4d7f45d1cf-5cf0a3206ecmr24575404a12.19.1731498036302; Wed, 13 Nov 2024 03:40:36 -0800 (PST) MIME-Version: 1.0 References: <202411131029.qchduffwgzhm@alvherre.pgsql> <3a93d9b1-e2a1-4d33-b9fc-702b8d43cdba@cloud.gatewaynet.com> In-Reply-To: From: Vijaykumar Jain Date: Wed, 13 Nov 2024 17:10:26 +0530 Message-ID: Subject: Re: Fwd: A million users To: Achilleas Mantzios - cloud Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000621d8c0626c9cd66" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000621d8c0626c9cd66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 13, 2024, 5:00=E2=80=AFPM Vijaykumar Jain < vijaykumarjain.github@gmail.com> wrote: > > > On Wed, Nov 13, 2024, 4:42=E2=80=AFPM Achilleas Mantzios - cloud < > a.mantzios@cloud.gatewaynet.com> wrote: > >> >> Exactly! In the later versions, security gets more and more refined and >> strengthened. So ppl should think about moving away from "public" , and >> start implementing finer grained schemes of security, as you suggest. + >> \dp shows prettier than having 1000+ users listed. >> > > I wanted to just communicate the limits. > a lot of postgresql architecture can leverage the resources and scale, bu= t > not all. > i had 100s of 1000s of tables on my setup where i worked last. > if i did \dt it would freeze all the time. i had to exit the pdwl session= , > check the source code of how the partition was named and then look for wh= at > I wanted. > if things are pretty with psql or not should not be a criteria for how > many objects you want to have. > > i would expect clear exceptions so one knows what the real problem is. > the error I got did not in anyway communicate the role limits for col siz= e > limits. > https://fluca1978.github.io/2018/01/04/PostgreSQLUsers.html so roles are not the problem. but if you grant them individually select on the same table for ex. then the limits are breached based of size of the col not number of permissions. > > --000000000000621d8c0626c9cd66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 13, 2024, 5:00=E2=80=AFPM Vijaykumar Jain = <vijaykumarjain.githu= b@gmail.com> wrote:


On Wed, Nov 13, 2024, 4:42=E2=80=AFPM Achilleas Mantzios - clo= ud <a.mantzios@cloud.gatewaynet.com> wrote:

Exactly! In the later versions, security gets more and more refined and strengthened. So ppl should think about moving away from "public"= , and
start implementing finer grained schemes of security, as you suggest. + \dp shows prettier than having 1000+ users listed.

I wanted to just communic= ate the limits.
a lot of postgresql architecture can= leverage the resources and scale, but not all.
i ha= d 100s of 1000s of tables on my setup where i worked last.
if i did \dt it would freeze all the time. i had to exit the pdwl se= ssion, check the source code of how the partition was named and then look f= or what I wanted.
if things are pretty with psql or = not should not be a criteria for how many objects you want to have.

i would expect clear exceptions= =C2=A0 so one knows what the real problem is.
the er= ror I got did not in anyway communicate the role limits for col size limits= .


so ro= les are not the problem.
but if you grant them indiv= idually select on the same table for ex. then the limits are breached based= of size of the col not number of permissions.

--000000000000621d8c0626c9cd66--