From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | michael(at)paquier(dot)xyz |
Cc: | exclusion(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: A comment in DropRole() contradicts the actual behavior |
Date: | 2024-02-08 08:43:17 |
Message-ID: | 20240208.174317.1876157164425004257.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Thu, 8 Feb 2024 16:39:23 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Thu, Feb 08, 2024 at 09:00:01AM +0300, Alexander Lakhin wrote:
> > 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():
>
> Well, these errors should never happen, IMHO, so it seems to me that
> the comment is right and that the code lacks locking, contrary to what
> the comment tells.
The function acquires a lock, but it does not perform an existence
check until it first attempts to fetch the tuple, believing in its
presence. However, I doubt performing an additional existence check
right after acquiring the lock is worthwhile.
By the way, I saw the following error with the provided script:
> ERROR: duplicate key value violates unique constraint "pg_authid_rolname_index"
> DETAIL: Key (rolname)=(u) already exists.
> STATEMENT: CREATE USER u;
This seems to be another instance of a similar thinko.
I vaguely think that we should just regard the absence as a concurrent
drop and either adjust or remove the message, then fix the
comment. The situation is slightly different for the duplication
case. We shouldn't ignore it but rather need to adjust the error
message. As long as these behaviors don't lead to inconsistencies.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2024-02-08 08:52:00 | Re: recently added jsonpath method change jsonb_path_query, jsonb_path_query_first immutability |
Previous Message | Sutou Kouhei | 2024-02-08 08:29:46 | Re: confusing / inefficient "need_transcoding" handling in copy |