Re: Implement UNLOGGED clause for COPY FROM

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Implement UNLOGGED clause for COPY FROM
Date: 2020-07-09 03:21:24
Message-ID: c7c94dc6-de56-fe87-4328-fc0567f6fee5@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/07/09 11:36, osumi(dot)takamichi(at)fujitsu(dot)com wrote:
> Hello, hackers.
>
>
> I've been thinking to suggest
> a peformance-oriented feature for COPY FROM.
> It's UNLOGGED clause, which means data loading skipping WAL generation.

This feature can work safely with wal_level=replica or logical?
Or it can work only with wal_level=minimal? If yes, what is the main
difference between this method and wal_skip_threshold?

>
> How to make it work is the following.
> 1. Aquire ACCESS EXCLUSIVE mode to lock the target table and its indexes.
> 2. Mark those relations 'unrecoverable' in pg_class/pg_index.
> 3. Issue one WAL to indicate when COPY UNLOGGED is executed.
> 4. Execute the data loading, bypassing WAL generation for data.
> 5. Sync the data to disk by performing checkpoint.

What happens if the server crashes before #5? Since no WAL for
data-loading can be replayed, the target table should be truncated?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2020-07-09 03:25:22 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message Amit Kapila 2020-07-09 03:17:22 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions