Re: A comment in DropRole() contradicts the actual behavior

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

In response to

Browse pgsql-hackers by date

  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