Message-ID: <4160bf8f-3101-2e5f-cca1-a75ca7c522f3@gmail.com>
Date: Sat, 11 Nov 2023 15:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: ResourceOwner refactoring
Content-Language: en-US
To: Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas
 <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>
Cc: Aleksander Alekseev <aleksander@timescale.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
 Julien Rouhaud <rjuju123@gmail.com>, Peter Eisentraut
 <peter@eisentraut.org>, Andres Freund <andres@anarazel.de>
References: 
 <CAOBaU_Z-NaqzAv=9YntFjbJhgWkJDAwCVyzvKUQTJ2UKgK4AOw@mail.gmail.com>
 <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>
 <d1bb4cfc-ce2b-4e20-bad7-7ae31c7b9cd0@iki.fi>
 <11b70743-c5f3-3910-8e5b-dd6c115ff829@gmail.com>
 <10399503-9a92-4107-8c36-698da29438db@iki.fi>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <10399503-9a92-4107-8c36-698da29438db@iki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/4160bf8f-3101-2e5f-cca1-a75ca7c522f3%40gmail.com>
Precedence: bulk

Hello Heikki,

10.11.2023 17:26, Heikki Linnakangas wrote:
>
> I think that is surprising behavior from the DSA facility. When you make allocations with dsa_allocate() or just call 
> dsa_get_address() on an existing dsa_pointer, you wouldn't expect the current resource owner to matter. I think 
> dsa_create/attach() should store the current resource owner in the dsa_area, for use in subsequent operations on the 
> DSA, per attached patch (0002-Fix-dsa.c-with-different-resource-owners.patch).
>

With the patch 0002 applied, I'm observing another anomaly:
CREATE TABLE t(t1 text, t2 text);
INSERT INTO t SELECT md5(g::text), '12345678901234567890' FROM generate_series(1, 100000) g;
CREATE INDEX tidx ON t(t1);

CREATE FUNCTION f() RETURNS TABLE (t1 text, t2 text) AS 'BEGIN END' LANGUAGE plpgsql;

SELECT * FROM f();

gives me under Valgrind:
2023-11-11 11:54:18.964 UTC|law|regression|654f5d2e.3c7a92|LOG: statement: SELECT * FROM f();
==00:00:00:49.589 3963538== Invalid read of size 1
==00:00:00:49.589 3963538==    at 0x9C8785: ResourceOwnerEnlarge (resowner.c:454)
==00:00:00:49.589 3963538==    by 0x7507C4: dsm_create_descriptor (dsm.c:1207)
==00:00:00:49.589 3963538==    by 0x74EF71: dsm_create (dsm.c:538)
==00:00:00:49.589 3963538==    by 0x9B7BEA: make_new_segment (dsa.c:2171)
==00:00:00:49.589 3963538==    by 0x9B6E28: ensure_active_superblock (dsa.c:1696)
==00:00:00:49.589 3963538==    by 0x9B67DD: alloc_object (dsa.c:1487)
==00:00:00:49.589 3963538==    by 0x9B5064: dsa_allocate_extended (dsa.c:816)
==00:00:00:49.589 3963538==    by 0x978A4C: share_tupledesc (typcache.c:2742)
==00:00:00:49.589 3963538==    by 0x978C07: find_or_make_matching_shared_tupledesc (typcache.c:2796)
==00:00:00:49.589 3963538==    by 0x977652: assign_record_type_typmod (typcache.c:1995)
==00:00:00:49.589 3963538==    by 0x9885A2: internal_get_result_type (funcapi.c:462)
==00:00:00:49.589 3963538==    by 0x98800D: get_expr_result_type (funcapi.c:299)
==00:00:00:49.589 3963538==  Address 0x72f9bf0 is 2,096 bytes inside a recently re-allocated block of size 16,384 alloc'd
==00:00:00:49.589 3963538==    at 0x4848899: malloc (vg_replace_malloc.c:381)
==00:00:00:49.589 3963538==    by 0x9B1F94: AllocSetAlloc (aset.c:928)
==00:00:00:49.589 3963538==    by 0x9C1162: MemoryContextAllocZero (mcxt.c:1076)
==00:00:00:49.589 3963538==    by 0x9C872C: ResourceOwnerCreate (resowner.c:423)
==00:00:00:49.589 3963538==    by 0x2CC522: AtStart_ResourceOwner (xact.c:1211)
==00:00:00:49.589 3963538==    by 0x2CD52A: StartTransaction (xact.c:2084)
==00:00:00:49.589 3963538==    by 0x2CE442: StartTransactionCommand (xact.c:2948)
==00:00:00:49.589 3963538==    by 0x992D69: InitPostgres (postinit.c:860)
==00:00:00:49.589 3963538==    by 0x791E6E: PostgresMain (postgres.c:4209)
==00:00:00:49.589 3963538==    by 0x6B13C4: BackendRun (postmaster.c:4423)
==00:00:00:49.589 3963538==    by 0x6B09EB: BackendStartup (postmaster.c:4108)
==00:00:00:49.589 3963538==    by 0x6AD0A6: ServerLoop (postmaster.c:1767)

without Valgrind I get:
2023-11-11 11:08:38.511 UTC|law|regression|654f60b6.3ca7eb|ERROR: ResourceOwnerEnlarge called after release started
2023-11-11 11:08:38.511 UTC|law|regression|654f60b6.3ca7eb|STATEMENT:  SELECT * FROM f();

Best regards,
Alexander