Horton

Re: In-placre persistance change of a relation

Heikki Linnakangas <hlinnaka@iki.fi>

View thread
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, michael@paquier.xyz
Cc: 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-10-28T13:33:41Z
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 31/08/2024 19:09, Kyotaro Horiguchi wrote:
> Subject: [PATCH v34 03/16] Remove function for retaining files on outer
>  transaction aborts
> 
> The function RelationPreserveStorage() was initially created to keep
> storage files committed in a subtransaction on the abort of outer
> transactions. It was introduced by commit b9b8831ad6 in 2010, but no
> use case for this behavior has emerged since then. If we move the
> at-commit removal feature of storage files from pendingDeletes to the
> UNDO log system, the UNDO system would need to accept the cancellation
> of already logged entries, which makes the system overly complex with
> no benefit. Therefore, remove the feature.

I don't think that's quite right. I don't think this was meant for 
subtransaction aborts, but to make sure that if the top-transaction 
aborts after AtEOXact_RelationMap() has already been called, we don't 
remove the new relation. AtEOXact_RelationMap() is called very late in 
the commit process to keep the window as small as possible, but if it 
nevertheless happens, the consequences are pretty bad if you remove a 
relation file that is in fact needed.

-- 
Heikki Linnakangas
Neon (https://neon.tech)