| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Postgres hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Subject: | Re: pgsql: Fix failure to check for open() or fsync() failures. |
| Date: | 2018-12-26 22:55:36 |
| Message-ID: | 26009.1545864936@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Wed, Dec 26, 2018 at 09:08:23PM +0000, Tom Lane wrote:
>> Fix failure to check for open() or fsync() failures.
>>
>> While it seems OK to not be concerned about fsync() failure for a
>> pre-existing signal file, it's not OK to not even check for open()
>> failure. This at least causes complaints from static analyzers,
> Wouldn't it be more simple to remove stat() and just call
> BasicOpenFilePerm, complaining with FATAL about any failures,
> including EACCES, on the way? The code is racy as designed, even if
> that's not a big deal for recovery purposes.
It appears to me that the code is intentionally not worrying about
fsync failure, so it seems wrong for it to FATAL out if it's unable
to open the file to fsync it. And it surely shouldn't do so if the
file isn't there.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-12-27 01:09:18 | Re: pgsql: Fix failure to check for open() or fsync() failures. |
| Previous Message | Michael Paquier | 2018-12-26 22:43:51 | Re: pgsql: Fix failure to check for open() or fsync() failures. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tsunakawa, Takayuki | 2018-12-26 23:45:52 | RE: removal of dangling temp tables |
| Previous Message | Noah Misch | 2018-12-26 22:44:28 | Re: Move regression.diffs of pg_upgrade test suite |