| From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Paul Guo <guopa(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Brown <michael(dot)brown(at)discourse(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fdatasync performance problem with large number of DB files |
| Date: | 2021-03-18 16:50:22 |
| Message-ID: | 3d1086bd-0881-e0a3-9f4f-bda608f07fdb@oss.nttdata.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2021/03/18 23:03, Bruce Momjian wrote:
>> Are we sure we want to use the word "crash" here? I don't remember
>> seeing it used anywhere else in our user interface.
We have GUC restart_after_crash.
> I guess it is
>> "crash recovery".
>
> Maybe call it "recovery_sync_method"
+1. This name sounds good to me. Or recovery_init_sync_method, because that
sync happens in the initial phase of recovery.
Another idea from different angle is data_directory_sync_method. If we adopt
this, we can easily extend this feature for other use cases (other than sync at
the beginning of recovery) without changing the name.
I'm not sure if such cases actually exist, though.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2021-03-18 16:55:39 | Re: Key management with tests |
| Previous Message | David Steele | 2021-03-18 16:50:11 | Re: Disable WAL logging to speed up data loading |