Re: In-placre persistance change of a relation

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>

To: nathandbossart@gmail.com

Cc: 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

Date: 2023-09-04T08:37:48Z

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 →

pg_dump: Refactor getIndexes()
- e2c52beecdea 15.0 cited
Optimize DropRelFileNodesAllBuffers() for recovery.
- bea449c635c0 14.0 cited

Attachments

v29-0001-Introduce-undo-log-implementation.patch (text/x-patch)

At Thu, 24 Aug 2023 11:22:32 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> I could turn this into something like undo longs in a simple form, but
> I'd rather not craft a general-purpose undo log system for this unelss
> it's absolutely necessary.

This is a patch for a basic undo log implementation. It looks like it
works well for some orphan-files-after-a-crash and data-loss-on-reinit
cases.  However, it is far from complete and likely has issues with
crash-safety and the durability of undo log files (and memory leaks
and performance and..).

I'm posting this to move the discussion forward.

(This doesn't contain the third file "ALTER TABLE ..ALL IN TABLESPACE" part.)

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center