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
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 |