MIME-Version: 1.0
References: 
 <CAHg+QDeP=mTHTV48R23zKMy1SBmCKZ_L7-z5zKnYyw+K0x-gCg@mail.gmail.com>
 <CAExHW5tsOK7ja2dMykD_qQSLwsuZxCTHx_jFyx-7-O+9WRBDXQ@mail.gmail.com>
 <CAHg+QDcXxmeiuySsyR5K=8Wk9Pq2sZ_4HNb6EMonN=yjLz_fyw@mail.gmail.com>
 <CAExHW5t2YtTMnK7qbvL++pBet-5B8bzgU+8wMcC5aqZwBH0C9w@mail.gmail.com>
 <CAHg+QDdAoW2cU2Wa-yKQs2awHxc19mkHGaAvDUZN=PZUDVsD=A@mail.gmail.com>
 <CAExHW5uThebnwqyWHrsF2Z+no-fT8VrM0Yj+RU7YWrYzdavUZg@mail.gmail.com>
 <CAExHW5tiOi=8Oq5Tza8gNz_jYmbWv+vb+p2fARUbfGnm-m7-9Q@mail.gmail.com>
 <3762a2e0-d3be-40e7-83d2-52dc3e1a21b2@eisentraut.org>
In-Reply-To: <3762a2e0-d3be-40e7-83d2-52dc3e1a21b2@eisentraut.org>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: Tue, 12 May 2026 07:05:06 +0530
Message-ID: 
 <CAExHW5tMT71BwGzA7VCi3_6ZVYh-P2JCVrUW84DD-jw+7+3KuA@mail.gmail.com>
Subject: Re: [Bug][patch]: After dropping the last label from a property graph
 element, invoking pg_get_propgraphdef() triggers an assertion failure
To: Peter Eisentraut <peter@eisentraut.org>
Cc: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAExHW5tMT71BwGzA7VCi3_6ZVYh-P2JCVrUW84DD-jw%2B7%2B3KuA%40mail.gmail.com>
Precedence: bulk

On Mon, May 4, 2026 at 8:16=E2=80=AFPM Peter Eisentraut <peter@eisentraut.o=
rg> wrote:
>
> On 28.04.26 17:02, Ashutosh Bapat wrote:
> > We are looking up element label catalogs twice in this patch - first
> > to find the label to be dropped and then to find the number of labels
> > associated with the given element. I combined these two into a single
> > while loop.
>
> That looks okay, but I think the names of the local variables are now a
> bit off.  I would expect elrel and elscan to refer to
> pg_propgraph_element, not pg_propgraph_element_label.  Maybe use
> ellabelrel etc.

Done.

>
> Also, I think this code needs to think a bit about locking to handle the
> situation where more than one DROP LABEL operation happens concurrently.
>

AlterPropGraph already takes ShareRowExclusiveLock at the beginning so
only one label can be dropped at a time. I have added an isolation
test to test the scenario. We could further add some more tests to
make sure that properties can not be added to a label being dropped,
adding label to an element being dropped, adding label to an element
being added etc. Would that be an overkill?

--=20
Best Wishes,
Ashutosh Bapat