Re: In-placre persistance change of a relation

Thom Brown <thom@linux.com>

From: Thom Brown <thom@linux.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: hlinnaka@iki.fi, michael@paquier.xyz, nathandbossart@gmail.com, postgres@jeltef.nl, smithpb2250@gmail.com, vignesh21@gmail.com, jakub.wartak@enterprisedb.com, stark.cfm@gmail.com, barwick@gmail.com, jchampion@timescale.com, pryzby@telsasoft.com, tgl@sss.pgh.pa.us, rjuju123@gmail.com, jakub.wartak@tomtom.com, pgsql-hackers@lists.postgresql.org, bharath.rupireddyforpostgres@gmail.com
Date: 2025-04-04T21:29:03Z
Lists: pgsql-hackers
On Fri, 27 Dec 2024 at 08:26, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
>
> Hello. This is the updated version.
>
> (Sorry for the delay; I've been a little swamped.)
>
> - Undo logs are primarily stored in a fixed number of fixed-length
>   slots and are spilled into files under some conditions.
>
>   The number of slots is 32 (ULOG_SLOT_NUM), and the buffer length is
>   1024 (ULOG_SLOT_BUF_LEN). Both are currently non-configurable.
>
> - Undo logs are now used only during recovery and no longer involved
>   in transaction ends for normal backends. Pending deletes for aborts
>   have been restored.
>
> - Undo logs are stored on a per-Top-XID basis.
>
> - RelationPreserverStorate() is no longer modified.
>
> In this version, in the part following the introduction of orphan
> storage prevention, the restriction on prepared transactions
> persisting beyond server crashes (i.e., the prohibition) has been
> removed. This is because handling for such cases has been reverted to
> pendingDeletes.
>
> Let me know if you have any questions or concerns.

I just went to give this a test drive, but HEAD has drifted too far,
at least for 0017 to apply. Could you please rebase and make the
necessary modifications?

Thanks

Thom