Re: remove more archiving overhead - Mailing list pgsql-hackers

From David Steele
Subject Re: remove more archiving overhead
Date
Msg-id 983e1c05-d479-dec3-b96e-0e5e359f5aa7@pgmasters.net
Whole thread Raw
In response to Re: remove more archiving overhead  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: remove more archiving overhead
List 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



pgsql-hackers by date:

Previous
From: Melih Mutlu
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Next
From: James Vanns
Date:
Subject: Weird behaviour with binary copy, arrays and column count