Re: In-placre persistance change of a relation

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: hlinnaka@iki.fi, 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: 2024-09-05T06:46:29Z
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.

At Mon, 2 Sep 2024 09:30:20 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Sun, Sep 01, 2024 at 10:15:00PM +0300, Heikki Linnakangas wrote:
> > 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..
> 
> Hmm.  It could be possible to extract some of this knowledge out of
> twophase.c and design some APIs that could be used for both, but would
> that be really necessary?  The 2PC data and the LSNs used by the files
> to check if things are replayed or on disk rely on
> GlobalTransactionData that has its own idea of things and timings at
> recovery.

I'm not sure, but I feel that Heikki mentioned only about using the
file format and in/out functions if the file formats of the two are
sufficiently overlapping.

> Or perhaps your point is actually to do that and add one layer for the
> file handlings and their flush timings?  I am not sure, TBH, what this
> thread is trying to fix is complicated enough that it may be better to
> live with two different code paths.  But perhaps my gut feeling is
> just wrong reading your paragraph.

I believe this statement is valid, so I’m not in a hurry to do this.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center