Tom Lane <t...@sss.pgh.pa.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