Re: thinko in basic_archive.c - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: thinko in basic_archive.c
Date
Msg-id 20221021.142557.146927729392165721.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: thinko in basic_archive.c  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
Sorry, the previous mail are sent inadvertently..

At Fri, 21 Oct 2022 14:13:46 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> +      expectation that a value will soon be provided. Care must be taken when
> +      multiple servers are archiving to the same
> +      <varname>basic_archive.archive_library</varname> directory as they all
> +      might try to archive the same WAL file.
> 
> I don't understand what kind of care should be taken by reading this..
> 
> Anyway the PID + millisecond-resolution timestamps work in the almost
> all cases, but it's not perfect. So.. I don't come up with what to
> think about this..
> 
> Traditionally we told people that "archiving should not overwrite a
> file unconditionally. Generally it is safe only when the contents are
> identical then should be errored-out otherwise.".. Ah this is.

basic_archive follows the suggestion if the same file exists before it
starts to write a file.  So please forget this.

>     * Sync the temporary file to disk and move it to its final destination.
>     * Note that this will overwrite any existing file, but this is only
>     * possible if someone else created the file since the stat() above.

I'm not sure why we are allowed to allow this behavior.. But it also
would be another issue, if anyone cares. Thus I feel that we might not
touch this description in this patch.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: thinko in basic_archive.c
Next
From: Michael Paquier
Date:
Subject: Re: Getting rid of SQLValueFunction