From: | Michal Charemza <michal(at)charemza(dot)name> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Extremely slow to establish connection when user has a high number of roles |
Date: | 2024-04-21 11:08:11 |
Message-ID: | CAJe2WWhUdndGyN8=7v53Kgj_TnW8apyzq-w2V7ncUd+Sytru8g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Do you do bulk
> permissions updates that might affect thousands of role memberships at
> once?
So we do regularly update role memberships - essentially a sync from a
separate database, and some could well have happened just before
connections, but it's more in the tens at a time at most, not thousands...
Or at least, that's what I thought. It sounds like it would be good to see
if it's doing more. It'll take some time for me to figure this out though...
> I'm fairly sure that if that exists it's always noticed first,
> bypassing the need for any role membership tests. So please
> confirm whether your production database has revoked PUBLIC
> connect privilege.
I realised that in fact we hadn't revoked this. So it sounds like whatever
the issue, it's not about checking if the user has the CONNECT privilege?
> It could be that the problem is not associated with the
> database's connect privilege, but with role membership lookups
> triggered by pg_hba.conf entries. Do you have any entries there
> that require testing membership (i.e. the role column is not
> "all")?
Running `select * from pg_hba_file_rules` it looks like the user column is
always {all} or {rdsadmin}
Thanks,
Michal
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-04-21 15:08:04 | Re: Extremely slow to establish connection when user has a high number of roles |
Previous Message | Tom Lane | 2024-04-20 15:52:47 | Re: Extremely slow to establish connection when user has a high number of roles |