Thread: 'WARNING: you don't own a lock of type ExclusiveLock' is printed during the GRANT command on PostgreSQL16.5
'WARNING: you don't own a lock of type ExclusiveLock' is printed during the GRANT command on PostgreSQL16.5
From
"Aya Iwata (Fujitsu)"
Date:
Hi developers, During our tests on November release, we discovered a "WARNING: you don't own a lock of type ExclusiveLock" that occurred at a strange time in GRANT command. [Details] Version: 16.5 OS: Linux Build options: --prefix=/xxx/xxx/xxx' '--with-ssl=openssl' '--without-icu Build and install command: make all make install Reproduction procedure: 1. Set binaries bin and lib path 2. Initiate the server using initdb command 3. create folder for tablespace 4. start the server usaing pg_ctl command 5. execute the following commands: This is only possible when psql executes each command individually. $ psql -d postgres -c "CREATE USER nmluser1;" CREATE ROLE $ psql -d postgres -c "CREATE TABLESPACE test_tblspace LOCATION '/xxx /xxx/pgsql16.5/tbs';" CREATE TABLESPACE $ psql -d postgres -c "CREATE DATABASE enc_testdb;" CREATE DATABASE $ psql -d postgres -c "GRANT ALL PRIVILEGES ON DATABASE postgres TO nmluser1;" GRANT $ psql -d postgres -c "GRANT ALL PRIVILEGES ON DATABASE enc_testdb TO nmluser1;" GRANT $ psql -d postgres -c "GRANT CREATE ON TABLESPACE test_tblspace TO nmluser1;" WARNING: you don't own a lock of type ExclusiveLock GRANT [Investigated] - This WARNING did not occur when tested with FEP16.4 using the same "Reproduction procedure:" - This WARNING did not occur when running CREATE ROLE through GRANT in a single session connected to psql. - Also, it did not happen when running 'psql -f' with an .sql file - We have run similar tests in the November releases of v12 through v17, but this is not reported by the tester in thosereleases. -- Therefore, we have not tried this "Reproduction procedure:" on versions other than 16.5 and 16.4. - This WARNING message appears in several places, and after modifying the source code to know which elog it is, seemed to come from ReleaseSysCache() in ExecGrant_common() Regards, Aya Iwata Fujitsu
Re: 'WARNING: you don't own a lock of type ExclusiveLock' is printed during the GRANT command on PostgreSQL16.5
From
Noah Misch
Date:
On Wed, Nov 20, 2024 at 05:11:07AM +0000, Aya Iwata (Fujitsu) wrote: > During our tests on November release, > we discovered a "WARNING: you don't own a lock of type ExclusiveLock" that occurred at a strange time in GRANT command. > > [Details] > Version: > 16.5 > 1. Set binaries bin and lib path > 2. Initiate the server using initdb command > 3. create folder for tablespace > 4. start the server usaing pg_ctl command > 5. execute the following commands: > > This is only possible when psql executes each command individually. > $ psql -d postgres -c "CREATE USER nmluser1;" > CREATE ROLE > $ psql -d postgres -c "CREATE TABLESPACE test_tblspace LOCATION '/xxx /xxx/pgsql16.5/tbs';" > CREATE TABLESPACE > $ psql -d postgres -c "CREATE DATABASE enc_testdb;" > CREATE DATABASE > $ psql -d postgres -c "GRANT ALL PRIVILEGES ON DATABASE postgres TO nmluser1;" > GRANT > $ psql -d postgres -c "GRANT ALL PRIVILEGES ON DATABASE enc_testdb TO nmluser1;" > GRANT > $ psql -d postgres -c "GRANT CREATE ON TABLESPACE test_tblspace TO nmluser1;" > WARNING: you don't own a lock of type ExclusiveLock > GRANT > > > [Investigated] > - This WARNING did not occur when tested with FEP16.4 using the same "Reproduction procedure:" > - This WARNING did not occur when running CREATE ROLE through GRANT in a single session connected to psql. > - Also, it did not happen when running 'psql -f' with an .sql file > - We have run similar tests in the November releases of v12 through v17, but this is not reported by the tester in thosereleases. > -- Therefore, we have not tried this "Reproduction procedure:" on versions other than 16.5 and 16.4. > - This WARNING message appears in several places, and after modifying the source code to know which elog it is, > seemed to come from ReleaseSysCache() in ExecGrant_common() Thanks for the report. This seems reasonably likely to come from a defect in commit 51ff46d. I will look into it.