| 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-27 02:30:49 |
| Message-ID: | 2389.1545877849@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 08:35:22PM -0500, Tom Lane wrote:
>> Oh, I see. Yeah, if we're ignoring errors anyway, the stat calls
>> seem redundant.
> For this one, I think that we could simplify as attached (this causes
> open() to fail additionally because of the sync flags, but that's not
> really worth worrying). Thoughts?
Actually, now that I think a bit more, this isn't a good idea. We want
standby_signal_file_found (resp. recovery_signal_file_found) to get set
if the file exists, even if we're unable to fsync it for some reason.
A counterexample to the proposed patch is that a signal file that's
read-only to the server will get ignored, which it should not be.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2018-12-27 09:05:40 | pgsql: pg_dump: Add missing newline to error message |
| Previous Message | Michael Paquier | 2018-12-27 02:10:39 | Re: pgsql: Fix failure to check for open() or fsync() failures. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-12-27 02:39:00 | Re: random() (was Re: New GUC to sample log queries) |
| Previous Message | Peter Geoghegan | 2018-12-27 02:20:20 | Re: random() (was Re: New GUC to sample log queries) |