From: Alexander Lakhin <exclusion@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
To: Robert Haas <robertmhaas@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Aleksander Alekseev <aleksander@timescale.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: Andres Freund <andres@anarazel.de>
Subject: Re: ResourceOwner refactoring
Date: Sat, 11 Nov 2023 15:00:00 +0300
Message-ID: <4160bf8f-3101-2e5f-cca1-a75ca7c522f3@gmail.com> (raw)
In-Reply-To: <10399503-9a92-4107-8c36-698da29438db@iki.fi>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: exclusion@gmail.com, hlinnaka@iki.fi, robertmhaas@gmail.com, thomas.munro@gmail.com, aleksander@timescale.com, rjuju123@gmail.com, peter@eisentraut.org, andres@anarazel.de
Subject: Re: ResourceOwner refactoring
In-Reply-To: <4160bf8f-3101-2e5f-cca1-a75ca7c522f3@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox