Re: remove more archiving overhead

From: David Steele <david(at)pgmasters(dot)net>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, robertmhaas(at)gmail(dot)com, masao(dot)fujii(at)oss(dot)nttdata(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: remove more archiving overhead
Date: 2022-07-08 17:02:51
Message-ID: 983e1c05-d479-dec3-b96e-0e5e359f5aa7@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/8/22 12:54, Nathan Bossart wrote:
> On Fri, Jul 08, 2022 at 08:20:09AM -0400, David Steele wrote:
>
>> Nathan, I don't see the language about being sure to persist to storage
>> here?
>
> It's here:
> When an archive library encounters a pre-existing file, it may return
> true if the WAL file has identical contents to the pre-existing archive
> and the pre-existing archive is fully persisted to storage.
>
> Since you didn't catch it, I wonder if it needs improvement. At the very
> least, perhaps we should note that one way to do the latter is to persist
> it yourself before returning true, and we could point to basic_archive.c as
> an example. However, I'm hesitant to make these docs too much more
> complicated than they already are. WDYT?

I think I wrote this before I'd had enough coffee. "fully persisted to
storage" can mean many things depending on the storage (Posix, CIFS, S3,
etc.) so I think this is fine. The basic_archive module is there for
people who would like implementation details for Posix.

Regards,
-David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message James Vanns 2022-07-08 17:08:24 Weird behaviour with binary copy, arrays and column count
Previous Message Melih Mutlu 2022-07-08 16:59:43 Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication