Horton

Re: In-placre persistance change of a relation

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, 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-02T00:30:20Z
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 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.

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.
--
Michael