Re: checking return value from unlink in write_relcache_init_file

From: Zhihong Yu <zyu(at)yugabyte(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: checking return value from unlink in write_relcache_init_file
Date: 2021-06-04 01:37:07
Message-ID: CALNJ-vQWn=dmBiB+YPCkPyZiC6piw3rSrMBFyvt5q0oghHt2mA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 3, 2021 at 6:16 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > On 2021-Jun-03, Tom Lane wrote:
> >> If the unlink fails, there's only really a problem if the subsequent
> >> open() fails to overwrite the file --- and that stanza is perfectly
> >> capable of complaining for itself. So I think the code is fine and
> >> there's no need for a separate message about the unlink. Refusing to
> >> proceed, as you've done here, is strictly worse than what we have.
>
> > It does seem to deserve a comment explaining this.
>
> Agreed, the existing comment there is a tad terse.
>
> regards, tom lane
>
Hi,
Here is the patch with a bit more comment on the unlink() call.

Cheers

Attachment Content-Type Size
comment-for-not-checking-unlink-return.patch application/octet-stream 711 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message tanghy.fnst@fujitsu.com 2021-06-04 02:55:01 RE: [BUG]Update Toast data failure in logical replication
Previous Message Tom Lane 2021-06-04 01:16:14 Re: checking return value from unlink in write_relcache_init_file