| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | nathandbossart(at)gmail(dot)com |
| Cc: | jakub(dot)wartak(at)enterprisedb(dot)com, stark(dot)cfm(at)gmail(dot)com, hlinnaka(at)iki(dot)fi, barwick(at)gmail(dot)com, jchampion(at)timescale(dot)com, pryzby(at)telsasoft(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, rjuju123(at)gmail(dot)com, jakub(dot)wartak(at)tomtom(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: In-placre persistance change of a relation |
| Date: | 2023-09-04 08:37:48 |
| Message-ID: | 20230904.173748.544222176732878202.horikyota.ntt@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
At Thu, 24 Aug 2023 11:22:32 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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
| Attachment | Content-Type | Size |
|---|---|---|
| v29-0001-Introduce-undo-log-implementation.patch | text/x-patch | 42.8 KB |
| v29-0002-In-place-table-persistence-change.patch | text/x-patch | 29.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2023-09-04 08:42:58 | Re: pg_upgrade and logical replication |
| Previous Message | Dilip Kumar | 2023-09-04 08:37:03 | Re: Optimize planner memory consumption for huge arrays |