| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Missing data_sync_elevel() for some calls of pg_fsync()? |
| Date: | 2019-12-02 04:58:26 |
| Message-ID: | 20191202045826.GF1696@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi all,
I was just looking at some callers of pg_fsync(), to notice that some
code paths don't use data_sync_elevel(). For some code paths, that's
actually better to never PANIC (say backup_label file, logical
decoding snapshot, lock file where FATAL/LOG are used now, etc.).
However I have spotted three code paths where this is not done and I
think that's not fine:
- 2PC file generated at checkpoint time.
- WAL segment initialization.
- Temporary state file for a replication slot save, which may cause
ERRORs at checkpoint time.
Any thoughts?
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| pgfsync-panic-v1.patch | text/x-diff | 1.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2019-12-02 05:30:47 | Re: pgbench -i progress output on terminal |
| Previous Message | 盏一 | 2019-12-02 04:22:37 | Re:Issue about memory order on ARM |