Re: ALTER TABLE uses a bistate but not for toast tables

Drouvot, Bertrand <bdrouvot@amazon.com>

From: "Drouvot, Bertrand" <bdrouvot@amazon.com>
To: Justin Pryzby <pryzby@telsasoft.com>, <pgsql-hackers@postgresql.org>
Date: 2022-09-07T08:48:39Z
Lists: pgsql-hackers
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