Re: In-placre persistance change of a relation

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, postgres@jeltef.nl, smithpb2250@gmail.com, vignesh21@gmail.com, jakub.wartak@enterprisedb.com, stark.cfm@gmail.com, hlinnaka@iki.fi, 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: 2024-06-05T04:52:21Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. pg_dump: Refactor getIndexes()

  2. Optimize DropRelFileNodesAllBuffers() for recovery.

On Tue, Jun 04, 2024 at 03:50:51PM -0500, Nathan Bossart wrote:
> Bharath, does the multi-INSERT stuff apply when changing a table to be
> LOGGED?  If so, I think it would be interesting to compare it with the FPI
> approach being discussed here.

The answer to this question is yes AFAIK.  Look at patch 0002 in the
latest series posted here, that touches ATRewriteTable() in
tablecmds.c where the rewrite happens should a relation's
relpersistence, AM, column or default requires a switch (particularly
if more than one property is changed in a single command, grep for
AT_REWRITE_*):
https://www.postgresql.org/message-id/CALj2ACUz5+_YNEa4ZY-XG960_oXefM50MjD71VgSCAVDkF3bzQ@mail.gmail.com

I've just read through the patch set, and they are rather pleasant to
the eye.  I have comments about them, actually, but that's a topic for
the other thread.
--
Michael