| From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | A comment in DropRole() contradicts the actual behavior |
| Date: | 2024-02-08 06:00:01 |
| Message-ID: | 9744e1e0-ad99-55f2-db8b-96aff46e105c@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello,
Please look at errors, which produced by the following script, starting
from 6566133c5:
for i in `seq 100`; do (echo "CREATE USER u; DROP USER u;"); done | psql >psql-1.log 2>&1 &
for i in `seq 100`; do (echo "CREATE USER u; DROP USER u;"); done | psql >psql-2.log 2>&1 &
wait
ERROR: could not find tuple for role 16387
ERROR: could not find tuple for role 16390
ERROR: could not find tuple for role 16394
...
Maybe these errors are expected, but then I'm confused by the comment in
DropRole():
/*
* Re-find the pg_authid tuple.
*
* Since we've taken a lock on the role OID, it shouldn't be possible
* for the tuple to have been deleted -- or for that matter updated --
* unless the user is manually modifying the system catalogs.
*/
tuple = SearchSysCache1(AUTHOID, ObjectIdGetDatum(roleid));
if (!HeapTupleIsValid(tuple))
elog(ERROR, "could not find tuple for role %u", roleid);
Best regards,
Alexander
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sutou Kouhei | 2024-02-08 06:03:08 | Re: meson: catalog/syscache_ids.h isn't installed |
| Previous Message | John Naylor | 2024-02-08 05:53:09 | Re: What about Perl autodie? |