Message-ID: <d1bb4cfc-ce2b-4e20-bad7-7ae31c7b9cd0@iki.fi>
Date: Thu, 9 Nov 2023 01:48:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: ResourceOwner refactoring
Content-Language: en-US
To: Alexander Lakhin <exclusion@gmail.com>,
 Peter Eisentraut <peter@eisentraut.org>, Andres Freund <andres@anarazel.de>
Cc: Aleksander Alekseev <aleksander@timescale.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
 Julien Rouhaud <rjuju123@gmail.com>, Robert Haas <robertmhaas@gmail.com>
References: 
 <CAOBaU_Z-NaqzAv=9YntFjbJhgWkJDAwCVyzvKUQTJ2UKgK4AOw@mail.gmail.com>
 <2e10b71b-352e-b97b-1e47-658e2669cecb@iki.fi>
 <20221101001523.lsgmohl6fjwppbgx@awork3.anarazel.de>
 <9a3245db-ca03-4a47-5706-73404cfe5108@iki.fi>
 <20221101154251.64vyq7wy6w7aykrn@awork3.anarazel.de>
 <bf88d2a9-a7bc-3d68-57e3-abfba87832e9@iki.fi>
 <CAJ7c6TNijrJ+0hnTiAPDBn-tCiJsk-yvpF3Y8rXG4gTw09JYbg@mail.gmail.com>
 <d17d4d6b-c39c-7e40-9f3d-b09f19e5ccec@iki.fi>
 <CAJ7c6TM_9XtQX6xAGkH2u2-b20z-1rii9szMdW-aMHJZC_NOsA@mail.gmail.com>
 <527af829-4a03-03b0-121c-46ff79c61887@iki.fi>
 <20230710191446.pn5ltm73t2i3xtxz@awork3.anarazel.de>
 <20607b96-b275-4a57-8509-29a3ed320d3f@iki.fi>
 <48b16f57-4204-4bd2-ab42-fb24144649c4@eisentraut.org>
 <bf814230-4172-47ce-a47c-6212ee6d298e@iki.fi>
 <9cb1277d-aee4-6511-44ee-7924676f7756@gmail.com>
 <599c6674-d40b-4b31-9251-c5c073ff9fdc@iki.fi>
 <be58d565-9e95-d417-4e47-f6bd408dea4b@gmail.com>
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <be58d565-9e95-d417-4e47-f6bd408dea4b@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/d1bb4cfc-ce2b-4e20-bad7-7ae31c7b9cd0%40iki.fi>
Precedence: bulk

On 08/11/2023 20:00, Alexander Lakhin wrote:
> Please look at a new assertion failure, I've managed to trigger with this script:
> CREATE TABLE t(
> i01 int, i02 int, i03 int, i04 int, i05 int, i06 int, i07 int, i08 int, i09 int, i10 int,
> i11 int, i12 int, i13 int, i14 int, i15 int, i16 int, i17 int, i18 int, i19 int, i20 int,
> i21 int, i22 int, i23 int, i24 int, i25 int, i26 int
> );
> CREATE TABLE tp PARTITION OF t FOR VALUES IN (1);
> 
> (gdb) bt
> ...
> #5  0x0000560dd4e42f77 in ExceptionalCondition (conditionName=0x560dd5059fbc "owner->narr == 0", fileName=0x560dd5059e31
> "resowner.c", lineNumber=362) at assert.c:66
> #6  0x0000560dd4e93cbd in ResourceOwnerReleaseAll (owner=0x560dd69cebd0, phase=RESOURCE_RELEASE_BEFORE_LOCKS,
> printLeakWarnings=false) at resowner.c:362
> #7  0x0000560dd4e92e22 in ResourceOwnerReleaseInternal (owner=0x560dd69cebd0, phase=RESOURCE_RELEASE_BEFORE_LOCKS,
> isCommit=false, isTopLevel=true) at resowner.c:725
> #8  0x0000560dd4e92d42 in ResourceOwnerReleaseInternal (owner=0x560dd69ce3f8, phase=RESOURCE_RELEASE_BEFORE_LOCKS,
> isCommit=false, isTopLevel=true) at resowner.c:678
> #9  0x0000560dd4e92cdb in ResourceOwnerRelease (owner=0x560dd69ce3f8, phase=RESOURCE_RELEASE_BEFORE_LOCKS,
> isCommit=false, isTopLevel=true) at resowner.c:652
> #10 0x0000560dd47316ef in AbortTransaction () at xact.c:2848
> #11 0x0000560dd47329ac in AbortCurrentTransaction () at xact.c:3339
> #12 0x0000560dd4c37284 in PostgresMain (dbname=0x560dd69779f0 "regression", username=0x560dd69779d8 "law") at
> postgres.c:4370
> ...

Thanks for the testing! Fixed. I introduced that bug in one of the last 
revisions of the patch: I changed ResourceOwnerSort() to not bother 
moving all the elements from the array to the hash table if the hash 
table is allocated but empty. However, ResourceOwnerReleas() didn't get 
the memo, and still checked "owner->hash != NULL" rather than 
"owner->nhash == 0".

-- 
Heikki Linnakangas
Neon (https://neon.tech)