[WIP PATCH v3] Implement "pg_restore --data-only --clean" as a way to skip WAL

From: Dimitrios Apostolou <jimis(at)gmx(dot)net>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: [WIP PATCH v3] Implement "pg_restore --data-only --clean" as a way to skip WAL
Date: 2025-06-16 01:06:56
Message-ID: 3eebf87a-2928-af48-ce96-c322ee113f62@gmx.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Attaching v3 of the patch, together with a new test file that tests
previously untested flags of pg_restore.

Added to July's commitfest:
https://commitfest.postgresql.org/patch/5821/

On Thu, 12 Jun 2025, Dimitrios Apostolou wrote:
> I wonder about the following in pg_restore.c.
> Right now my implementation covers only parallel restore.
> In the case of non-parallel restore, I want to make the behaviour similar,
> i.e. each worker to issue a TRUNCATE before COPY starts.
> But then the StartTransaction() doesn't make sense, as everything might
> already be in a transaction because of --single-transaction.
> Should I completely skip StartTransaction() if !is_parallel?

In the end, I followed the same code path for both parallel and
non-parallel pg_restore. It works even with --single-transaction, where
apparently there are several nested transactions.

The tests pass, so I assume it's OK to start a subtransaction for each
table restoration inside the global single-transaction.

Dimitris

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitrios Apostolou 2025-06-16 01:09:10 Re: [WIP PATCH v3] Implement "pg_restore --data-only --clean" as a way to skip WAL
Previous Message Sungwoo Chang 2025-06-16 00:02:22 Re: Fwd: dsm_registry: Add detach and destroy features