| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fsync error handling in pg_receivewal, pg_recvlogical |
| Date: | 2019-03-29 13:05:05 |
| Message-ID: | 20190329130505.GG1954@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 29, 2019 at 12:48:09PM +0100, Peter Eisentraut wrote:
> Do we need to review the fsync error handling in pg_receivewal and
> pg_recvlogical, following the recent backend changes? The current
> default behavior is that these tools will log fsync errors and then
> reconnect and proceed with the next data streaming in. As a result, you
> might then have some files in the accumulated WAL that have not been
> fsynced. Perhaps a hard exit would be more appropriate?
Yes, I think that we are going to need an equivalent of that for all
frontend tools. At various degrees, making sure that a fsync happens
is also important for pg_dump, pg_basebackup, pg_rewind and
pg_checksums so it is not only a problem of the two tools you mention.
It seems to me that the most correct way to have those failures would
be to use directly exit(EXIT_FAILURE) in file_utils.c where
appropriate.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2019-03-29 13:11:47 | Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru |
| Previous Message | Peter Eisentraut | 2019-03-29 12:56:51 | Re: Add exclusive backup deprecation notes to documentation |