Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pdrhq-0004zM-VK for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Mar 2023 12:00:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pdrho-0007ZX-Tt for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Mar 2023 12:00:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pdrho-0007YL-Gi for pgsql-hackers@lists.postgresql.org; Sun, 19 Mar 2023 12:00:08 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pdrhl-0001ZY-DI for pgsql-hackers@lists.postgresql.org; Sun, 19 Mar 2023 12:00:08 +0000 Received: by mail-lj1-x230.google.com with SMTP id b13so9415631ljf.6 for ; Sun, 19 Mar 2023 05:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679227203; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=AJWs2XwbvdQUfskrgo9XKb8CL/gXXklAGkDY1G6eBOU=; b=O7voj5pbIgtsUaIevOB4/NuBrBzmi4gpRllNw3ALkAxFyoYCdRpqDQLzVZF3H9sCWz O+t20LAg0bQU62hv4bLv4Dkr47DYAhyrECjUcLH7mvkYT+nD66FUNC1I8DO4PkLrkVwt Cj9ta7iWMBZsi0O3ZuPIwGU0kHOgOuWPhZvOAdnSE89oOzNxF+Ahr8otJUb6zBMXlBlp UE0dRKz7spzND7LkVl0pFyq7HiT0NCg/KG5Gnz1WF0v7WngoZyNml6jxC54pFq+B4s28 uywKKCqgFi9kPX7crLr7RZc18mChWIVityrSPBVh7tV7ACvNJqL8E69aBhUysESM1+1p pEDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679227203; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=AJWs2XwbvdQUfskrgo9XKb8CL/gXXklAGkDY1G6eBOU=; b=Y0KUkRe7R5KDanzHzczzgcVqc/IPzKgNeL/O9jCoVqcYAr5GIXsuPtM5MBmPQs96BU UgQU6Hg8PnAwss7vmSDCzZrnizpxybe5kTMxQn8M8wfkOrt+fvkMJaH2graLqtB2Jwih a6P8FXCFZqYKHPzlOwc84bPOL+izUjrzWGka/EBTbu5tV10FNBXdyWP2HUW8RxSCbGf2 82KB6xLSr4kGdzgKCcjTSk6oPQWUc3AydltEF/mLaNrxbDLLx+Ox9NNvv1pBiudA440o Bq72OxDuLGA51Wtc788WTVo+4O5gTnepZ+0xYsJ+hf5Gw8YUYe539wf2e0KA6QSujGFD 7NHg== X-Gm-Message-State: AO0yUKWfS/j7Emhd7rX4e3dC276lcbm9AWX8hF810YwaRxJKau9ELa1x dpnnqiMsDxt3V1N9SfTCcm4= X-Google-Smtp-Source: AK7set8nqj41oDS1rxCmD8E6YGsm/IlvJ/rj9PN0qW2W8o6vRw0wSRX6rORbyCkqbE24Ovy5uLat7w== X-Received: by 2002:a2e:be2a:0:b0:294:6fc7:2648 with SMTP id z42-20020a2ebe2a000000b002946fc72648mr7001238ljq.39.1679227203241; Sun, 19 Mar 2023 05:00:03 -0700 (PDT) Received: from [1.0.0.7] ([178.155.5.7]) by smtp.gmail.com with ESMTPSA id e10-20020a056512090a00b004db2ca9dd33sm1233717lft.275.2023.03.19.05.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Mar 2023 05:00:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------e1OzXQdPF0W5XOxHSZx8YoP7" Message-ID: <4995256b-cc65-170e-0b22-60ad2cd535f1@gmail.com> Date: Sun, 19 Mar 2023 15:00:01 +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: Extending outfuncs support to utility statements Content-Language: en-US To: Peter Eisentraut , Tom Lane Cc: Andres Freund , pgsql-hackers@lists.postgresql.org References: <4159834.1657405226@sss.pgh.pa.us> <9b197806-17ee-acba-0e70-01263aa46e79@enterprisedb.com> <1972439.1657665506@sss.pgh.pa.us> <2e7adbce-2ff5-866e-8753-9969b0ce332b@enterprisedb.com> <20220922153257.r5wj74prdqrucnov@awork3.anarazel.de> <1415326.1663863390@sss.pgh.pa.us> <1418391.1663865327@sss.pgh.pa.us> <20220922170103.6tnwbpzeddceiyyl@awork3.anarazel.de> <1944074.1663880234@sss.pgh.pa.us> <1946183.1663881687@sss.pgh.pa.us> From: Alexander Lakhin In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------e1OzXQdPF0W5XOxHSZx8YoP7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello, 26.09.2022 17:46, Peter Eisentraut wrote: > On 22.09.22 23:21, Tom Lane wrote: >> Anyway, this is a bit far afield from the stated topic of this >> thread.  I think we should commit something approximately like >> what I posted and then start a new thread specifically about >> what we'd like to do about utility commands in new-style SQL >> functions. > > Right, I have committed everything and will close the CF entry.  I don't have a specific idea about how to move > forward right now. Please look at the function _readA_Const() (introduced in a6bc33019), which fails on current master under valgrind: CPPFLAGS="-DUSE_VALGRIND -DWRITE_READ_PARSE_PLAN_TREES -Og " ./configure -q --enable-debug && make -s -j8 && make check ============== creating temporary instance            ============== ============== initializing database system           ============== pg_regress: initdb failed Examine .../src/test/regress/log/initdb.log for the reason. initdb.log contains: performing post-bootstrap initialization ... ==00:00:00:02.155 3419654== Invalid read of size 16 ==00:00:00:02.155 3419654==    at 0x448691: memcpy (string_fortified.h:29) ==00:00:00:02.155 3419654==    by 0x448691: _readA_Const (readfuncs.c:315) ==00:00:00:02.155 3419654==    by 0x44CCD2: parseNodeString (readfuncs.switch.c:129) ==00:00:00:02.155 3419654==    by 0x4348D6: nodeRead (read.c:338) ==00:00:00:02.155 3419654==    by 0x434879: nodeRead (read.c:452) ==00:00:00:02.155 3419654==    by 0x440E6C: _readTypeName (readfuncs.funcs.c:830) ==00:00:00:02.155 3419654==    by 0x44CC3A: parseNodeString (readfuncs.switch.c:121) ==00:00:00:02.155 3419654==    by 0x4348D6: nodeRead (read.c:338) ==00:00:00:02.155 3419654==    by 0x43D51D: _readFunctionParameter (readfuncs.funcs.c:2513) ==00:00:00:02.155 3419654==    by 0x44DE0C: parseNodeString (readfuncs.switch.c:367) ==00:00:00:02.155 3419654==    by 0x4348D6: nodeRead (read.c:338) ==00:00:00:02.155 3419654==    by 0x434879: nodeRead (read.c:452) ==00:00:00:02.155 3419654==    by 0x438A9C: _readCreateFunctionStmt (readfuncs.funcs.c:2499) ==00:00:00:02.155 3419654==  Address 0xf12f718 is 0 bytes inside a block of size 8 client-defined ==00:00:00:02.155 3419654==    at 0x6A70C3: MemoryContextAllocZeroAligned (mcxt.c:1109) ==00:00:00:02.155 3419654==    by 0x450C31: makeInteger (value.c:25) ==00:00:00:02.155 3419654==    by 0x434D59: nodeRead (read.c:482) ==00:00:00:02.155 3419654==    by 0x448690: _readA_Const (readfuncs.c:313) ==00:00:00:02.155 3419654==    by 0x44CCD2: parseNodeString (readfuncs.switch.c:129) ==00:00:00:02.155 3419654==    by 0x4348D6: nodeRead (read.c:338) ==00:00:00:02.155 3419654==    by 0x434879: nodeRead (read.c:452) ==00:00:00:02.155 3419654==    by 0x440E6C: _readTypeName (readfuncs.funcs.c:830) ==00:00:00:02.155 3419654==    by 0x44CC3A: parseNodeString (readfuncs.switch.c:121) ==00:00:00:02.155 3419654==    by 0x4348D6: nodeRead (read.c:338) ==00:00:00:02.155 3419654==    by 0x43D51D: _readFunctionParameter (readfuncs.funcs.c:2513) ==00:00:00:02.155 3419654==    by 0x44DE0C: parseNodeString (readfuncs.switch.c:367) ==00:00:00:02.155 3419654== Here _readA_Const() performs:                 union ValUnion *tmp = nodeRead(NULL, 0);                 memcpy(&local_node->val, tmp, sizeof(*tmp)); where sizeof(union ValUnion) = 16, but nodeRead()->makeInteger() produced Integer (sizeof(Integer) = 8). Best regards, Alexander --------------e1OzXQdPF0W5XOxHSZx8YoP7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello,

26.09.2022 17:46, Peter Eisentraut wrote:
On 22.09.22 23:21, Tom Lane wrote:
Anyway, this is a bit far afield from the stated topic of this
thread.  I think we should commit something approximately like
what I posted and then start a new thread specifically about
what we'd like to do about utility commands in new-style SQL
functions.

Right, I have committed everything and will close the CF entry.  I don't have a specific idea about how to move forward right now.

Please look at the function _readA_Const() (introduced in a6bc33019), which fails on current master under valgrind:
CPPFLAGS="-DUSE_VALGRIND -DWRITE_READ_PARSE_PLAN_TREES -Og " ./configure -q --enable-debug && make -s -j8 && make check

============== creating temporary instance            ==============
============== initializing database system           ==============

pg_regress: initdb failed
Examine .../src/test/regress/log/initdb.log for the reason.

initdb.log contains:
performing post-bootstrap initialization ... ==00:00:00:02.155 3419654== Invalid read of size 16
==00:00:00:02.155 3419654==    at 0x448691: memcpy (string_fortified.h:29)
==00:00:00:02.155 3419654==    by 0x448691: _readA_Const (readfuncs.c:315)
==00:00:00:02.155 3419654==    by 0x44CCD2: parseNodeString (readfuncs.switch.c:129)
==00:00:00:02.155 3419654==    by 0x4348D6: nodeRead (read.c:338)
==00:00:00:02.155 3419654==    by 0x434879: nodeRead (read.c:452)
==00:00:00:02.155 3419654==    by 0x440E6C: _readTypeName (readfuncs.funcs.c:830)
==00:00:00:02.155 3419654==    by 0x44CC3A: parseNodeString (readfuncs.switch.c:121)
==00:00:00:02.155 3419654==    by 0x4348D6: nodeRead (read.c:338)
==00:00:00:02.155 3419654==    by 0x43D51D: _readFunctionParameter (readfuncs.funcs.c:2513)
==00:00:00:02.155 3419654==    by 0x44DE0C: parseNodeString (readfuncs.switch.c:367)
==00:00:00:02.155 3419654==    by 0x4348D6: nodeRead (read.c:338)
==00:00:00:02.155 3419654==    by 0x434879: nodeRead (read.c:452)
==00:00:00:02.155 3419654==    by 0x438A9C: _readCreateFunctionStmt (readfuncs.funcs.c:2499)
==00:00:00:02.155 3419654==  Address 0xf12f718 is 0 bytes inside a block of size 8 client-defined
==00:00:00:02.155 3419654==    at 0x6A70C3: MemoryContextAllocZeroAligned (mcxt.c:1109)
==00:00:00:02.155 3419654==    by 0x450C31: makeInteger (value.c:25)
==00:00:00:02.155 3419654==    by 0x434D59: nodeRead (read.c:482)
==00:00:00:02.155 3419654==    by 0x448690: _readA_Const (readfuncs.c:313)
==00:00:00:02.155 3419654==    by 0x44CCD2: parseNodeString (readfuncs.switch.c:129)
==00:00:00:02.155 3419654==    by 0x4348D6: nodeRead (read.c:338)
==00:00:00:02.155 3419654==    by 0x434879: nodeRead (read.c:452)
==00:00:00:02.155 3419654==    by 0x440E6C: _readTypeName (readfuncs.funcs.c:830)
==00:00:00:02.155 3419654==    by 0x44CC3A: parseNodeString (readfuncs.switch.c:121)
==00:00:00:02.155 3419654==    by 0x4348D6: nodeRead (read.c:338)
==00:00:00:02.155 3419654==    by 0x43D51D: _readFunctionParameter (readfuncs.funcs.c:2513)
==00:00:00:02.155 3419654==    by 0x44DE0C: parseNodeString (readfuncs.switch.c:367)
==00:00:00:02.155 3419654==

Here _readA_Const() performs:
                union ValUnion *tmp = nodeRead(NULL, 0);

                memcpy(&local_node->val, tmp, sizeof(*tmp));

where sizeof(union ValUnion) = 16, but nodeRead()->makeInteger() produced Integer (sizeof(Integer) = 8).

Best regards,
Alexander
--------------e1OzXQdPF0W5XOxHSZx8YoP7--