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 1oVqkr-0002HL-Lo for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Sep 2022 08:49:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oVqkq-0000eI-Hu for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Sep 2022 08:49:52 +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 1oVqkp-0000e8-Sw for pgsql-hackers@lists.postgresql.org; Wed, 07 Sep 2022 08:49:52 +0000 Received: from smtp-fw-80006.amazon.com ([99.78.197.217]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVqkn-0006mW-Rq for pgsql-hackers@postgresql.org; Wed, 07 Sep 2022 08:49:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1662540589; x=1694076589; h=message-id:date:mime-version:from:subject:to:references: in-reply-to; bh=v0G3qCT3v7rKHZFbI8WgcXZB3cwV11kDhDxwe8wbc6g=; b=Gqlao7nPVsj/X0ASOE/c38qmfs3jMMJAlozm+OQhAcYL2CxfnMKGz/IV 1FW5YbPSNQPB9JnRwQMVjFkqPdpYlTIrZUXCuXYHAMjpkZ7gdctluSYV0 L24HknNXQwTcY6CaBqVR2Z04vpi8GwvYJp+Ua8Vns/azWX3mMuoQM2wea E=; X-IronPort-AV: E=Sophos;i="5.93,296,1654560000"; d="scan'208,217";a="127462484" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-pdx-2b-02ee77e7.us-west-2.amazon.com) ([10.25.36.210]) by smtp-border-fw-80006.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2022 08:48:43 +0000 Received: from EX13D03EUC003.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-pdx-2b-02ee77e7.us-west-2.amazon.com (Postfix) with ESMTPS id D73EF45056; Wed, 7 Sep 2022 08:48:42 +0000 (UTC) Received: from [192.168.25.177] (10.43.166.36) by EX13D03EUC003.ant.amazon.com (10.43.164.192) with Microsoft SMTP Server (TLS) id 15.0.1497.38; Wed, 7 Sep 2022 08:48:40 +0000 Content-Type: multipart/alternative; boundary="------------0zF61ZQaZnE40CZfi58XTInL" Message-ID: Date: Wed, 7 Sep 2022 10:48:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 From: "Drouvot, Bertrand" Subject: Re: ALTER TABLE uses a bistate but not for toast tables To: Justin Pryzby , References: <20220622143841.GS22452@telsasoft.com> Content-Language: en-US In-Reply-To: <20220622143841.GS22452@telsasoft.com> X-Originating-IP: [10.43.166.36] X-ClientProxiedBy: EX13D39EUC003.ant.amazon.com (10.43.164.139) To EX13D03EUC003.ant.amazon.com (10.43.164.192) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --------------0zF61ZQaZnE40CZfi58XTInL Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Hi, On 6/22/22 4:38 PM, Justin Pryzby wrote: > ATRewriteTable() calls table_tuple_insert() with a bistate, to avoid clobbering > and polluting the buffers. > > But heap_insert() then calls > heap_prepare_insert() > > heap_toast_insert_or_update > > toast_tuple_externalize > > toast_save_datum > > heap_insert(toastrel, toasttup, mycid, options, NULL /* without bistate:( */); Good catch! > I came up with this patch. +       /* Release pin after main table, before switching to write to toast table */ +       if (bistate) +               ReleaseBulkInsertStatePin(bistate); I'm not sure we should release and reuse here the bistate of the main table: it looks like that with the patch ReadBufferBI() on the main relation wont have the desired block already pinned (then would need to perform a read). What do you think about creating earlier a new dedicated bistate for the toast table? +       if (bistate) +       { +               table_finish_bulk_insert(toastrel, options); // XXX I think it's too early, as it looks to me that at this stage we may have not finished the whole bulk insert yet. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services:https://aws.amazon.com --------------0zF61ZQaZnE40CZfi58XTInL Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

Hi,

On 6/22/22 4:38 PM, Justin Pryzby wrote:
ATRewriteTable() calls table_tuple_insert() with a bistate, to avoid clobbering
and polluting the buffers.

But heap_insert() then calls
heap_prepare_insert() >
heap_toast_insert_or_update >
toast_tuple_externalize >
toast_save_datum >
heap_insert(toastrel, toasttup, mycid, options, NULL /* without bistate:( */);

Good catch!

I came up with this patch.  

+       /* Release pin after main table, before switching to write to toast table */
+       if (bistate)
+               ReleaseBulkInsertStatePin(bistate);

I'm not sure we should release and reuse here the bistate of the main table: it looks like that with the patch ReadBufferBI() on the main relation wont have the desired block already pinned (then would need to perform a read).

What do you think about creating earlier a new dedicated bistate for the toast table?

+       if (bistate)
+       {
+               table_finish_bulk_insert(toastrel, options); // XXX

I think it's too early, as it looks to me that at this stage we may have not finished the whole bulk insert yet.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
--------------0zF61ZQaZnE40CZfi58XTInL--