From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: ResourceOwner refactoring |
Date: | 2023-11-11 12:00:00 |
Message-ID: | 4160bf8f-3101-2e5f-cca1-a75ca7c522f3@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2023-11-11 12:38:59 | Re: autovectorize page checksum code included elsewhere |
Previous Message | Christoph Berg | 2023-11-11 11:53:37 | Re: pgsql: Don't trust unvalidated xl_tot_len. |