Re: In-placre persistance change of a relation

On 31/08/2024 19:09, Kyotaro Horiguchi wrote:
> - UNDO log(0002): This handles file deletion during transaction aborts,
>    which was previously managed, in part, by the commit XLOG record at
>    the end of a transaction.
> 
> - Prevent orphan files after a crash (0005): This is another use-case
>    of the UNDO log system.

Nice, I'm very excited if we can fix that long-standing issue! I'll try 
to review this properly later, but at a quick 5 minute glance, one thing 
caught my eye:

This requires fsync()ing the per-xid undo log file every time a relation 
is created. I fear that can be a pretty big performance hit for 
workloads that repeatedly create and drop small tables. Especially if 
they're otherwise running with synchronous_commit=off. Instead of 
flushing the undo log file after every write, I'd suggest WAL-logging 
the undo log like regular relations and SLRUs. So before writing the 
entry to the undo log, WAL-log it. And with a little more effort, you 
could postpone creating the files altogether until a checkpoint happens, 
similar to how twophase state files are checkpointed nowadays.

I wonder if the twophase state files and undo log files should be merged 
into one file. They're similar in many ways: there's one file per 
transaction, named using the XID. I haven't thought this fully through, 
just a thought..

> +static void
> +undolog_set_filename(char *buf, TransactionId xid)
> +{
> +    snprintf(buf, MAXPGPATH, "%s/%08x", SIMPLE_UNDOLOG_DIR, xid);
> +}

I'd suggest using FullTransactionId. Doesn't matter much, but seems like 
a good future-proofing.

-- 
Heikki Linnakangas
Neon (https://neon.tech)